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

[Kubalewski, Arkadiusz]

>From: Ivan Vecera <ivecera@xxxxxxxxxx>
>Sent: Monday, June 15, 2026 2:00 PM
>
>On 6/11/26 2:09 PM, Jiri Pirko wrote:
>> Wed, Jun 10, 2026 at 05:45:46PM +0200, ivecera@xxxxxxxxxx wrote:
>>> On 6/10/26 3:04 PM, Kubalewski, Arkadiusz wrote:
>>>>> 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.
>>>
>>> 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.

Now you said yourself "NCO mode" ... I agree that it would be a mode in
that case. Where instead of running on regular/built in XO dpll would run
on NCO and user could select it, and this would be addition to regular
behavior.

I also agree that the pin approach might be better/easier to use, assuming
frequency offset for all the outputs given dpll drives, it makes more sense
to have it configurable on input side.

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

I don't know 'current' HW that is capable of using AUTO mode as a part of
HW-based priority source selection and use such NCO input..
But as already explained above, this is special mode of regular XO, which
allows DPLL's output frequency offset configuration.

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

Agree, 'override' capability of a pin would be the way to go for this and
other similar further cases.

I believe a single approach on this would be best, I mean if AUTO mode
needs a capability, to switch from regular behavior to 'OVERRIDE', and
'OVERRIDE' is only pin capability that allows such behavior for AUTO
mode, then similar approach should be used on MANUAL mode, to make
userspace know that such pin is always available to set "CONNECTED"
and make the userspace implementation consistent on enabling it no matter
if AUTO or MANUAL mode dpll.

Thank you!
Arkadiusz