-----Original Message-----
From: Min Li
Sent: February 18, 2021 11:14 AM
To: 'Arnd Bergmann' <[email protected]>
Cc: Derek Kiernan <[email protected]>; Dragan Cvetic <[email protected]>; Arnd Bergmann <[email protected]>; gregkh <[email protected]>; [email protected]; Networking <[email protected]>; Richard Cochran <[email protected]>
Subject: RE: [PATCH net-next] misc: Add Renesas Synchronization Management Unit (SMU) support
> -----Original Message-----
> From: Arnd Bergmann <[email protected]>
> Sent: February 18, 2021 5:51 AM
> To: Min Li <[email protected]>
> Cc: Derek Kiernan <[email protected]>; Dragan Cvetic
> <[email protected]>; Arnd Bergmann <[email protected]>; gregkh
> <[email protected]>; [email protected]; Networking
> <[email protected]>; Richard Cochran <[email protected]>
> Subject: Re: [PATCH net-next] misc: Add Renesas Synchronization
> Management Unit (SMU) support
>
> On Thu, Feb 18, 2021 at 4:28 AM Min Li <[email protected]> wrote:
> > > If the driver can use the same algorithm that is in your user
> > > space software today, that would seem to be a nicer way to handle
> > > it than requiring a separate application.
> > >
> >
> > Hi Arnd
> >
> >
> > What is the device driver that you are referring here?
> >
> > In summary of your reviews, are you suggesting me to discard this
> > change and go back to PTP subsystem to find a better place for
> > things that I wanna do here?
>
> Yes, I mean doing it all in the PTP driver.
>
> Arnd
Hi Arnd
The APIs I am adding here is for our development of assisted partial timing support (APTS), which is a Global Navigation Satellite System (GNSS) backed by Precision Time Protocol (PTP).
So it is not part of PTP but they can work together for network timing solution.
What I am trying to say is the things that I am adding here doesn't really belong to the PTP world.
For example, timex->freq is different from the ffo that I am reading from this driver since the DPLL is Working in different mode. For PTP, DPLL is working in DCO mode. In DCO mode, the DPLL control loop is opened and the DCO can be controlled by a PTP clock recovery servo running on an external processor to synthesize PTP clocks. On the other hand for GNSS timing, the ffo I am reading here is when DPLL is in locked mode. In Locked the long-term output frequency accuracy is the same as the long-term frequency accuracy of the selected input reference.
For our GNSS APTS development, we have 2 DPLL channels, one channel is locked to GNSS and another channel is PTP channel.
If GNSS channel is locked, we use GNSS's channel to support network timing. Otherwise, we switch to PTP channel.
To think about it, our device is really an multi functional device (MFD), which is why I am submitting another review for our MFD driver on the side. We have our PTP driver and we have this for GNSS APTS and other misc functions.
So can you take a look at this again and see if it makes sense to keep this change simply because the change is not part of PTP subsystem.
They sound like they are related. But when it comes to technicality, there is really no place in PTP to hold stuff that I am doing here.
Thanks
Min