On Wed, 5 Jun 2019 at 20:45, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Wed, Jun 05, 2019 at 02:33:52PM +0300, Vladimir Oltean wrote: > > In the meantime: Richard, do you have any objections to this patchset? > > I like the fact that you didn't have to change the dsa or ptp > frameworks this time around. I haven't taken a closer look than that > yet. >
There's one more thing I wanted to ask you if you get the chance to take a closer look. 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. On the other hand I get much tighter sync offset using the free-running counter than with hardware-corrected timestamps. So as far as I see it, I'll need to have two sets of operations. 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? 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 was wondering whether the path delay difference between E2E and P2P > > rings any bell to you. > > Can it be that the switch applies corrections in HW? > > Thanks, > Richard Thanks, -Vladimir
