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

[Ivan Vecera <ivecera@redhat.com>]

On 6/11/26 2:09 PM, Jiri Pirko wrote:
> 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.
> 
Arek? Vadim?

Thanks,
Ivan