Re: [PATCH v3 net-next 00/17] PTP support for the SJA1105 DSA driver

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, 6 Jun 2019 at 06:11, Richard Cochran <richardcochran@gmail.com> wrote:
>
> On Wed, Jun 05, 2019 at 09:08:54PM +0300, Vladimir Oltean wrote:
> > Currently I'm using a cyclecounter, but I *will* need actual PHC
> > manipulations for the time-based shaping and policing features that
> > the switch has in hardware.
>
> Okay.
>
> > On the other hand I get much tighter sync
> > offset using the free-running counter than with hardware-corrected
> > timestamps.
>
> Why?  The time stamps come from the very same counter, don't they?
>

Plain and simply because it doesn't work very well.
Even phc2sys from the system clock to the hardware (no timestamps
involved) has trouble staying put (under 1000 ns offset).
And using the hardware-corrected timestamps triggers a lot of clockchecks.

> > So as far as I see it, I'll need to have two sets of
> > operations.
>
> I doubt very much that this will work well.
>
> > How should I design such a dual-PHC device driver? Just register two
> > separate clocks, one for the timestamping counter, the other for the
> > scheduling/policing PTP clock, and have phc2sys keep them in sync
> > externally to the driver?
>
> But how would phc2sys do this?  By comparing clock_gettime() values?
> That would surely introduce unnecessary time error.
>
> > Or implement the hardware corrections
> > alongside the timecounter ones, and expose a single PHC (and for
> > clock_gettime, just pick one of the time sources)?
>
> I would implement the hardware clock and drop the timecounter
> altogether.
>
> HTH,
> Richard