On Fri, 26 Jun 2020 at 07:20, Richard Cochran <richardcoch...@gmail.com> wrote: > > On Fri, Jun 26, 2020 at 12:21:01AM +0300, Vladimir Oltean wrote: > > Actually there's no good reason why ts2phc would specify an absolute > > start time of (current time + 2 seconds, 0) for its most basic > > operation. The (0, 0) start time should be accepted by all drivers, > > Hm. I'm not so sure that all drivers accept start times in the past. > If some drivers reject zero start time, then we'll have to make this a > configuration option... > > Thanks, > Richard >
So I grepped in the current mainline kernel for "perout.*start" and most drivers just don't seem to care that the time may be in the past, and just write what they're given. - sja1105 rolls the time over into the closest phase-equivalent future time - mlx5 _assumes_ the time is in the future, since it programs a value into the hardware based on "nsec_delta = ns - nsec_now;". I'm not actually sure how that plays out with phase alignment. - ocelot needs "start" to be 0. - idt82p33 needs "start.nsec" to be 0 and doesn't care beyond that. But, in the general sense, who knows whether a value in the past will work for these pieces of hardware. Generally speaking, I would say it's squarely the responsibility of the driver to adjust the start time if needed. As far as we currently know, entropy only goes one way*, and if we let the application ask for a "far enough" time in the future (currently 2 seconds), that, to me, is a bit sloppier since the kernel might be so busy that there's no guarantee really that 2 seconds in the future won't actually wind up being in the PTP device's past anyway by the time the driver gets to write it. *Although clock stepping makes that challenging. But I don't know how many drivers still treat perout correctly after a clock step, and I'm not even sure what the correct treatment would be. So, to your point: I didn't see any driver that _rejects_ time in the past. If it works, I don't know. If it doesn't work, I would do the time fixup at driver level, so in my opinion there's no need for an application-level flag. What do you think? Thanks, -Vladimir _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
