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

[Jiri Pirko <jiri@resnulli.us>]

Wed, Jun 10, 2026 at 05:45:46PM +0200, ivecera@redhat.com wrote:
>On 6/10/26 3:04 PM, Kubalewski, Arkadiusz wrote:
>> > From: Ivan Vecera <ivecera@redhat.com>
>> > Sent: Tuesday, June 9, 2026 4:59 PM
>> > 
>> > On 6/9/26 4:00 PM, Kubalewski, Arkadiusz wrote:
>> > > > From: Jiri Pirko <jiri@resnulli.us>
>> > > > Sent: Tuesday, June 9, 2026 10:51 AM
>> > > > 
>> > > > Mon, Jun 08, 2026 at 07:03:46PM +0200, arkadiusz.kubalewski@intel.com
>> > > > wrote:
>> > > > > > From: Ivan Vecera <ivecera@redhat.com>
>> > > > > > Sent: Monday, June 8, 2026 5:48 PM
>> > > > > > 
>> > > > > > On 6/8/26 4:43 PM, Kubalewski, Arkadiusz wrote:
>> > > > > > > > From: Ivan Vecera <ivecera@redhat.com>
>> > > > > > > > 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?

I agree with you, the driver should have the flexibility to implement
this according to his/hw's needs/capabilities. If it implements prio
selection in AUTO mode, let it have it. If it implements manual NCO pin
selection in AUTO mode using connected/disconnected override, let it
have it.

Moreover, I actually like the "override" capability for pins in AUTO
mode in general. It may be handy for other usecases as well.