Re: [PATCH 07/10] clk: amlogic: Support POWER_OF_TWO for PLL pre-divider

[Jian Hu <jian.hu@amlogic.com>]

On 5/20/2026 3:35 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mer. 20 mai 2026 at 13:47, Jian Hu <jian.hu@amlogic.com> wrote:
>
>> On 5/14/2026 11:11 PM, Jerome Brunet wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>>>
>>>> From: Jian Hu <jian.hu@amlogic.com>
>>>>
>>>> The A9 PLL pre-divider uses a division factor of 2^n to ensure a clock
>>>> duty cycle of 50% after predivision.
>>>>
>>>> Add flag 'CLK_MESON_PLL_N_POWER_OF_TWO' to indicate that the PLL
>>>> pre-divider division factor is 2^n.
>>> I understand what you are doing here but I have to ask why this can't be
>>> implemented with independent dividers that already supports power of 2 ?
>>
>> If we use independent dividers, the n member would have to be removed from
>> meson_clk_pll_data.
>>
>> However, n is referenced 35 times in clk-pll.c, which means we would need
>> to modify all
>> related logic across the file. This would be a relatively large
>> change.
> Yes
>
>>
>> Moreover, for all Amlogic chips, the n divider is an indispensable part of
>> the DCO clock.
> There is hardly a justification here
>
>> The difference between SoC generations is as follows:
>>      Previous SoCs PLL: n = 1, 2, 3, 4... (linear divider)
>>      A9 SoC PLL:            n = 2^0, 2^1, 2^2, 2^3, 2^4... (power-of-two
>> divider)
> Yes that was fairly obvious
>
>> Therefore, splitting out the n divider from the DCO clock might not be a
>> good design choice.
> I'm not sure I agree and you've only stated your point of view without
> providing any technical justification here.
>
>  From the datasheets of the different SoC we have, the documented
> limitation is always the DCO output rate range. Nothing related to n (or
> m, or the mult-range for that matter). This is a legacy problem, we
> started with monolithic driver and slowly simplified it.
>
> As far as I can see now, reworking the PLL driver to be a simple
> multiplier driver with range output rate constraint could actually be
> simpler than the current code. I would also make simpler to accomodate
> differences such as the one presented here.
>
> Unless you can provide technical reasons why going in this direction
> would be incorrect, that's where I'd prefer to go.
>
>> [...]
>>
>> Best regards,
>>
>> Jian
> --
> Jerome


I agree that having an independent N divider would simplify the PLL rate 
calculation.

A separate pre-divider for N is technically possible, but there are some
hardware constraints that need to be considered:

N = 1 is the preferred operating mode except a few fixed-frequency PLLs.
Larger N values reduce the PLL phase detector frequency, which may 
negatively impact
jitter performance and overall PLL stability.

Because of this, we cannot guarantee stable system operation when 
arbitrary larger
N values are used.

Some PLLs require non-1 N values to generate specific fixed output 
frequencies because
the target rate cannot be achieved with N = 1 while keeping the PLL 
while keeping the
PLL within its valid operating range. So N is designed to have other 
values ​​to
satisfy this requirement.

For example, the AXG PCIe PLL uses N = 3 to generate the required 100 
MHz output frequency,
since the target frequency cannot be achieved with N = 1.


Additionally, is the refactored pre-divider N implemented as a separate 
patchset,
independent from the A9 PLL changes?


Best regards,


Jian