-----Original Message----- From: Min Li Sent: February 18, 2021 11:14 AM To: 'Arnd Bergmann' <a...@kernel.org> Cc: Derek Kiernan <derek.kier...@xilinx.com>; Dragan Cvetic <dragan.cve...@xilinx.com>; Arnd Bergmann <a...@arndb.de>; gregkh <gre...@linuxfoundation.org>; linux-ker...@vger.kernel.org; Networking <netdev@vger.kernel.org>; Richard Cochran <richardcoch...@gmail.com> Subject: RE: [PATCH net-next] misc: Add Renesas Synchronization Management Unit (SMU) support
> -----Original Message----- > From: Arnd Bergmann <a...@kernel.org> > Sent: February 18, 2021 5:51 AM > To: Min Li <min.li...@renesas.com> > Cc: Derek Kiernan <derek.kier...@xilinx.com>; Dragan Cvetic > <dragan.cve...@xilinx.com>; Arnd Bergmann <a...@arndb.de>; gregkh > <gre...@linuxfoundation.org>; linux-ker...@vger.kernel.org; Networking > <netdev@vger.kernel.org>; Richard Cochran <richardcoch...@gmail.com> > Subject: Re: [PATCH net-next] misc: Add Renesas Synchronization > Management Unit (SMU) support > > On Thu, Feb 18, 2021 at 4:28 AM Min Li <min.li...@renesas.com> 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
