RE: [Intel-wired-lan] [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825

[Kubalewski, Arkadiusz]

>From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf Of
>Jakub Kicinski
>Sent: Thursday, April 16, 2026 5:28 PM
>
>On Wed, 15 Apr 2026 13:23:22 +0000 Kubalewski, Arkadiusz wrote:
>> >> Well, the true is that we did not anticipated per-port control of the
>> >> TX clock source, as a single DPLL device could drive multiple of
>> >> such.
>> >>
>> >> This is not true, that we pretend there is a second PLL - there is a
>> >> PLL on each TX clock, maybe not a full DPLL, but still the loop with
>> >> a control over it's sources is there and it has the same 2 external
>> >> sources + default XO.
>> >
>> >Don't we put that MAC PLL into bypass mode if we feed a clock from
>> >the EEC DPLL?
>>
>> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
>> external from NIC point of view. Only 2 signals from such external DPLL
>> device are used by NIC:
>> - synce (a single source for all those TXC per-port DPLL device)
>> - time_ref (a source for the TS_PLL - which drives PTP timer)
>
>No bypass? The PLL is actually in the loop? oof, this is beyond
>my understanding of clocks and signals :S
>

TBH, I am not entirely sure what do you mean with MAC PLL into bypass
mode, but the HW description I have provided is still true, the MAC is
not fed with any DPLL provided signal here. Only port tx clocks PLLs and
a timer PLL can use those.

>> >> A mentioned try of adding per port MUX-type pin, just to give some
>> >> control
>> >> to the user, is where we wanted to simplify things, but in the end
>> >> the
>> >> API
>> >> would have to be modified in significant way, various paths related
>> >> to
>> >> pin
>> >> registration and keeping correct references, just to make working
>> >> case
>> >> for the pin_on_pin_register and it's internals. We decided that the
>> >> burden
>> >> and impact for existing design was to high.
>> >>
>> >> And that is why the TXC approach emerged, the change of DPLL is
>> >> minimal,
>> >> The model is still correct from user perspective, SyncE SW controller
>> >> shall
>> >> anticipate possibility that per-port TXC dpll is there
>> >
>> >We are starting to push into what was previously the domain of
>> >drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
>> >clock dividers. And cannot be "configured" after chip init / async
>> >reset (which is why I presume you whack a reset in patch 7?).
>>
>> Well, we need CGU-dividers change for a frequency-compliance with lower
>> link speeds, the link reset which is required as part of tx-clk switch
>> and link establishment on a new clock.
>>
>> >
>> >> This particular device and driver doesn't implement any EEC-type DPLL
>> >> device, the one could think that we can just change the type here and
>> >> use
>> >> EEC type instead of new one TXC - since we share pins from external
>> >> dpll
>> >> driver, which is EEC type, and our DPLL device would have different
>> >> clock_id
>> >> and module. But, further designs, where a single NIC is having
>> >> control
>> >> over
>> >> both a EEC DPLL and ability to control each source per-port this
>> >> would
>> >> be
>> >> problematic. At least one NIC Port driver would have to have 2 EEC-
>> >> type
>> >> DPLLs
>> >> leaving user with extra confusion.
>> >
>> >The distinction between TXC and EEC dpll is confusing.
>> >I thought EEC one _was_supposed_to_ drive the Tx clock?
>> >What PPS means is obvious, what EEC means if not driving Tx clock is
>> >unclear to me..
>> >
>>
>> Yes, correct, EEC DPLL main task would be to drive TX clocks of NIC
>> ports, but if there is a per-port control something extra is required.
>>
>> >Let me summarize my concerns - we need to navigate the split between
>> >drivers/clk and dpll. We need a distinction on what goes where, because
>> >every ASIC has a bunch of PLLs which until now have been controlled by
>> >device tree (if at all). If the main question we want to answer is
>> >"which clock ref is used to drive internal clock" all we need is a MUX.
>> >If we want to make dpll cover also ASIC PLLs for platforms without
>> >device tree we need a more generic name than TXC, IMHO.
>>
>> Well, 'floating' MUX type pin not connected to any dpll would require a
>> lot of additional implementations, just to allow source selection, as we
>> have tried it already.
>>
>> Wouldn't more generic name cause a DPLL purpose problem?
>
>The old proposal in netdev family was to to have source selection
>without creating a real mux. Not saying I'm dead set on that direction.
>

Yes, correct, it kept the list of dpll pins valid for source selection of
tx clock within the netdev and control over it through RT netlink.
That solution was rather simple but you requested to hack into dpll so we
did here.

IMHO this is cleanest and simplest solution we could find to keep it
within DPLL subsystem.

>> We still want to make sure that given DPLL device would serve the role
>> of source selection for particular port where a source pin should be an
>> output either on EEC dpll or some external signal generator but somehow
>> related to SyncE or similar solutions.
>
>Right, but adding a new "type" per location of the PLL (especially if
>we lean into covering any ASIC PLL) may not scale, and opens us up to
>"vendor X calls it Y" and "in design A clock is fed by pll type X and
>in design B by type Y".
>

I was thinking that this is more like a purpose specific DPLL device, if
someone would want something similar we would have to review it, right?

>IIUC you do provide "linking" of the pins? netdev will have the MAC pin
>assigned. Is the pin that connects the PLLs also annotated so that user
>knows what's on the "other side"? Maybe the topology would be clear
>enough from just that, and we don't have to add a TXC type.
>Call the PLL "integrated" or something generic. User should be able to
>trace the path of the signals?

It depends, TX clock has one of external pins connected to external DPLL,
but second is a board-level pin with ability to provide some external
clock signal, the user would have to determine that purpose just based
on the topology of one of the pins, which seems a bit problematic?
I.e. if at some point there would be HW with only external non-DPLL
connected pins?

I mean 'generic' type is something we could do, but as already mentioned,
thought that we want a DPLL types specified/designed for some particular
functions/tasks. 

Thank you!
Arkadiusz