Re: [PATCH net-next v5 1/4] dpll: add DPLL_PIN_TYPE_INT_NCO pin type

[Ivan Vecera]

On 6/10/26 3:04 PM, Kubalewski, Arkadiusz wrote:
> > From: Ivan Vecera <ivecera@xxxxxxxxxx>
> > Sent: Tuesday, June 9, 2026 4:59 PM
> >
> > On 6/9/26 4:00 PM, Kubalewski, Arkadiusz wrote:
> > > > From: Jiri Pirko <jiri@xxxxxxxxxxx>
> > > > Sent: Tuesday, June 9, 2026 10:51 AM
> > > >
> > > > Mon, Jun 08, 2026 at 07:03:46PM +0200, arkadiusz.kubalewski@xxxxxxxxx
> > > > wrote:
> > > > > > From: Ivan Vecera <ivecera@xxxxxxxxxx>
> > > > > > Sent: Monday, June 8, 2026 5:48 PM
> > > > > >
> > > > > > On 6/8/26 4:43 PM, Kubalewski, Arkadiusz wrote:
> > > > > > > > From: Ivan Vecera <ivecera@xxxxxxxxxx>
> > > > > > > > Sent: Sunday, May 31, 2026 9:44 PM ...
> > > > > > > >          -
> > > > > > > >            name: gnss
> > > > > > > >            doc: GNSS recovered clock
> > > > > > > > +      -
> > > > > > > > +        name: int-nco
> > > > > > > > +        doc: |
> > > > > > > > +          Device internal numerically controlled oscillator.
> > > > > > > > +          When connected as a DPLL input, the DPLL enters NCO mode
> > > > > > > > +          where the output frequency is adjusted by the host via
> > > > > > > > +          the PTP clock interface.
> > > > > > >
> > > > > > > Hi Ivan!
> > > > > > >
> > > > > > > How would you control this in case of automatic mode dpll?
> > > > > > > Automatic mode DPLL shall be controlled on HW level, such pin
> > > > > > > brakes that rule and requires some driver magic to show it is
> > > > > > > higher priority then the rest of the pins?
> > > > > >
> > > > > > The NCO pin can be connected only in manual mode. In other words a
> > > > > > DPLL in automatic mode cannot select NCO pin (switch to NCO mode) by
> > > > > > its own.
> > > > >
> > > > > Being picky on DPLL_MODE for enabling feature is not something we
> > > > > can allow if it is not related to HW limitation, is it?
> > > > > Could you please elaborate why it is not possible for AUTOMATIC mode?
> > > >
> > > > In automatic mode, the pin selection logic is defined upon prio. I
> > > > can imagine that if NCO pin has the highest prio of the available
> > > > ones, it gets picked. I would be aligned 100% with automatic mode
> > > > behaviour.
> > > > Is there a real usecase for it?
> > > >
> > > > [..]
> > >
> > > This is not true. AUTOMATIC mode is HW solution, SW driver ONLY
> > > configures priorities on the inputs, not manages the active inputs.
> > > This brakes that behavior, the SW driver would have to manually
> > > override the AUTMATIC mode to be fed from such NCO pin as it doesn't
> > > exists on it's priority list, HW cannot pick or use it.
> >
> > Correct, AUTO mode is hardware feature and it should not be emulated by a
> > driver. If the hardware does not support it then the switching between
> > input references should be done by userspace (by monitoring ffo,
> > phase_offset, operstate).
>
> Yes, exactly, so for AUTOMATIC mode HW it will not be possible to create
> such pin, which means that NCO pin would serve only a MANUAL mode
> implementation.
> Basically this is something we shall not allow to happen. DPLL API
> should be designed to cover the case where AUTO mode is able to implement
> all features consistently.

If you don't like the proposal from Jiri (NCO switch driven by NCO pin
priority -> highest==enter_nco else leave_nco) then it could be possible
to handle the switching by allowing the state 'connected' in AUTO mode
for the NCO pin type. Then the implementation will be the same for both
selection modes.

Only difference would be that a user does not need to switch the device
from the AUTO to MANUAL mode.

> > > The real use case is that any DPLL can switch the mode to this one
> > > instead of implementing MANUAL mode just to use the feature with a
> > > 'virtual' pin.
> >
> > I don't expect this... but it is up to a driver. I don't plan such
> > functionality in zl3073x as the NCO pin does not expose prio_get() and
> > prio_set() callbacks - so it is clear that this pin cannot be part of the
> > automatic selection.
> >
> > Ivan
>
> There is a difference between particular HW and API capabilities, with the
> proposed API we would disallow the possibility of such implementation for
> existing HW variants.
>
> DPLL NCO MODE would allow that but as pointed here by Ivan and by Jiri in
> the other email it would also require the extra implementation for some
> configuration - device level phase/ffo handling.
>
> To summarize it all, I don't have such simple solution for it.
>
> First thing that comes to my mind is to combine both approaches.
> Make it possible for AUTMATIC mode to also set "CONNECTED" state
> on certain kind of "OVERRIDE" pins, where it could be determined by
> the type of PIN and embed that logic into the DPLL subsystem.

The possible states for particual pins are now handled at a driver level
so the driver decides if the requested state is correct or not. So it
could be easy to implement this.

For auto mode allowed states:
- input references: selectable / disconnected
- nco pin: connected / disconnected

> Basically, if driver registers such NCO pin it would be always selected
> manually, and in such case all the other pins are going to disconnected
> state while DPLL mode is also a "OVERRIDE" or something like it.

I would leave this decision on the driver level... Imagine the potential
HW that would allow to switch NCO mode if there is no valid input
reference.

Example:

REF0 (prio 0) -> +------+ -> OUT0
REF1 (prio 1) -> | DPLL | -> ...
NCO  (prio 2) -> +------+ -> OUTn

Such HW would prefer REF0 or REF1 and lock to one of them if they are
qualified. But if they are NOT, then it switches to NCO mode.

In this situation the relevant driver would allow to configure priority
and state 'selectable' for this NCO pin.

> Perhaps the pin type could include OVERRIDE in it's name to make it less
> confusing and needs some extra documentation.
>
> Thoughts?
I think _INT_ is ok. In the case of TYPE_INT_OSCILLATOR it is also
obvious that it is not a standard input reference.

Jiri, Vadim, Arek, thoughts?

Thanks,
Ivan