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

[Ivan Vecera]

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.

If the DPLL device is in automatic mode then a user has to switch the
device to manual mode and then manually set the NCO pin as connected.

> Such NCO mode/pin is designed only for this single specific use case
> where a timecard contains a DPLL and PHC?

This is designed for a HW where DPLL channels (devices) support ToD
counters (can act as PHC besides DPLL functionality) and support the
mode where DPLL is not locked to any physical input and allows tuning
of its frequency.

> Any diagram?
>
> Is there any other use case for such pin? (NCO is rather a general
> DPLL control mechanism?) Shouldn't it be called explicitly like
> ptp-nco?
I discussed this with Jiri and result was:
- DPLL_MODE is input selection strategy
- NCO is a case of manual selection strategy

And *_INT_PTP_NCO or *_PTP_NCO?

Yes, this could be reasonable... I can't think of anything else to use
other than PTP... for now (can be changed in future).

Thanks,
Ivan