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

[Ivan Vecera <ivecera@redhat.com>]

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

> 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