Re: [PATCH v2 05/10] arm64: dts: rockchi p: rk3568: add XPCS and fixed-clock nodes

On August 2, 2026 11:19:37 PM GMT+08:00, Andrew Lunn <andrew@lunn=2Ech> wro=
te:
>On Sun, Aug 02, 2026 at 11:28:12AM +0800, Coia Prant wrote:
>> Hi Andrew,
>>=20
>> Thanks for the detailed questions=2E I've looked into the clock tree
>> more carefully=2E
>>=20
>> > Do you have documentation for these Combo PHYs?
>>=20
>> Yes, the information is available in the Rockchip RK3568 TRM
>> (Technical Reference Manual)=2E
>> The relevant clock tree details are also mentioned in upstream
>> discussions and patches=2E
>>=20
>> > Can these clocks be enabled/disabled?
>>=20
>> The 100 MHz input clock to the Combo PHY is a prerequisite for its oper=
ation=2E
>> It is generated by the SoC's internal PPLL and fed to the PHY through
>> a fixed divider=2E
>> It is not a gate that can be individually enabled or disabled by
>> software; it is part of the
>> PHY's fundamental operating conditions=2E
>>=20
>> > And how is the Combo PHY fed with a clock? Does it have an external o=
scillator/crystal?
>>=20
>> The Combo PHY is fed by an internal 100 MHz clock derived from the PPLL=
=2E
>> Specifically, the PPLL runs at 200 MHz, and this is divided by 2 to pro=
vide the
>>  100 MHz clock input to the Combo PHY=2E
>> So, it does not use an external oscillator or crystal for its main
>> reference clock;
>> it's generated internally by the SoC=2E
>>=20
>> To summarize:
>> - The 125 MHz clocks (xpcs_gmac0_clk / xpcs_gmac1_clk) are outputs
>> from the Combo PHY=2E
>> - The Combo PHY itself is clocked by an internal 100 MHz clock from the=
 PPLL=2E
>> - This is all internal to the SoC and does not involve a board-level os=
cillator=2E
>>=20
>> I hope this clarifies the clock architecture=2E
>
>So what is the purpose of the fixed-clock DT nodes?
>
>If you want to describe the hardware, is the PPLL in DT? Should you
>then add a fixed divider to give 100MHz? And then a fixed multiplier
>to give 125MHz?
>
>   Andrew

Hi Andrew,

Thanks for the follow-up=2E

The fixed-clock nodes (`xpcs_gmac0_clk` and `xpcs_gmac1_clk`) serve as
clock inputs to the GMAC controller=2E From the GMAC driver's perspective,
the 125 MHz clock is a fixed, external input=2E The fact that it's
generated internally by the Combo PHY from the PPLL is an implementation
detail of the SoC, not something the GMAC driver needs to be aware of=2E

In the device tree, the principle is to describe the hardware
interfaces, not the entire internal clock generation pipeline=2E The
PPLL configuration (200 MHz) is already set up in the CRU node via
assigned-clocks=2E The Combo PHY's internal PLL that generates 125 MHz is
part of the PHY's own operation, not something that the system clock
framework needs to manage or represent as a separate clock node=2E

If we were to fully model PPLL -> divider (100 MHz) -> Combo PHY PLL
(125 MHz) in DT, we would be overcomplicating the DT for no real gain=2E
It would also make board variations harder to handle (e=2Eg=2E, if a board
uses an external oscillator instead of the internal path, we'd have to
rewrite the entire clock tree)=2E This approach is consistent with how
other similar SoCs (e=2Eg=2E, pcs-xpcs-plat) handle fixed reference clocks=
=2E

I think keeping these as fixed-clock nodes is the right balance between
accuracy and simplicity=2E If you still have concerns, I can add a comment
in the DT to clarify that these clocks are outputs of the Combo PHY=2E

Thanks,
Coia