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

[Ivan Vecera]

On 6/9/26 12:24 PM, Vadim Fedorenko wrote:
> On 08/06/2026 16:30, Ivan Vecera wrote:
> > On 6/8/26 1:33 PM, Vadim Fedorenko wrote:
> > > On 04/06/2026 17:42, Ivan Vecera wrote:
> > > > On 6/4/26 5:16 PM, Jakub Kicinski wrote:
> > > > > On Thu, 4 Jun 2026 17:01:36 +0200 Ivan Vecera wrote:
> > > > > > > Purely going on intuition here but feels like NCO should be a mode
> > > > > > > (enum dpll_mode) rather than one of the input pins?
> > > > > > >
> > > > > > > More acks here would be great, Vadim, Arkadiusz, Grzegorz... ?
> > > > > >
> > > > > > I had a long discussion with Jiri about this and we agreed finally
> > > > > > that dpll_mode represents a reference (input pin) selection strategy
> > > > > > mode and not a DPLL device running mode.
> > > > >
> > > > > Long discussion? I see 2 emails ;) Let's hear from others.
> > > > > (thanks for the link BTW, _if_ there's a v6 please put it in the cover
> > > > > letter)
> > > >
> > > > I called him... he explained me 'why?' in detail.
> > > > I also appreciate others' opinion.
> > >
> > > Well, NCO mode means manual operation of frequency tuning. Does it mean
> > > that different tunings may be applied to different out pins of DPLL
> > > device? My assumption that it's not possible, and in this case NCO is
> > > property/mode of DPLL device rather than single pin.
> >
> > The NCO pin is only one per device... When it is connected, then the
> > device the pin is connected to is switched to NCO mode. In this mode
> > the device is not locked to any input reference and the driver allows
> > tuning of the DPLL frequency manually via PTP interface.
> >
> > Such tuning is applied only to output pins associated with this device
> > but not on others.
> >
> > Examples:
> > DPLL0 is driving output 0-3 and DPLL1 is driving output 4-7.
> > Then if you switch the DPLL0 to NCO mode (makes NCO pin connected to it)
> > then frequency tuning (via PTP) has only influence on output 0-3 (the
> > same tuning is applied). Outputs 4-7 are not touched as they are driven
> > by DPLL1 (that can be locked to some input reference).
> >
> > If you switch both DPLLs to NCO, then frequency tuning for DPLL0 affects
> > output 0-3 and tuning for DPLL1 output 4-7.
>
> Technically speaking you have described per-device behavior. And NCO pin
> can technically be virtual, just a configuration option via normal
> device communication channel. Doesn't feel like pin's attribute. Back in
> a days of DPLL RFC patches we have discussed the option with Arkadiusz,
> AFAIR we were leaning towards per-DPLL state for this case.

Frequency fine tuning is not the subject of this patchset. It is
currently part of the PTP API via the .adjfine() callback. I have not
added this feature yet, because it would be a duplication of part of the
PTP API, but if there is a consensus, we can add it as a per-device
attribute.

Something like dpll device attributes:
* fractional-frequency-adjust
  - corresponds to .adjfine()
  - tunes dpll device frequency (usable mostly in NCO mode because when
    the device is locked to physical reference then its frequency is
    driven by this ref)
* phase-adjust
  - corresponds to .adjphase()
  - adjusts phase of all outputs driven by this dpll device performed
    at once

Thanks,
Ivan