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

[Kubalewski, Arkadiusz]

>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.

>> 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.

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.

Perhaps the pin type could include OVERRIDE in it's name to make it less
confusing and needs some extra documentation.

Thoughts?