> What I don't understand is how is your FPGA different from a NIC. In both cases there is a clock which is timestamping packets and PPS on an input pin, right?
Correct. I may have overstated the case for WHERE the hardware timestamping happens (in the NIC or elsewhere). The real issue is about what needs to happen afterwards. The offsets need to be used to train the PHC clock. And the chrony SOCK refclock like mechanism was one option. But I think you are suggesting that the samples can be fed through an ioctl instead. Am I reading you correctly? On Tue, Jun 11, 2019 at 9:37 AM Miroslav Lichvar <mlich...@redhat.com> wrote: > On Tue, Jun 11, 2019 at 09:30:53AM -0400, Sanjay Bhandari wrote: > > > How is timestamping GPS PPS different from timestamping external > events? > > If the driver could provide this feature using the existing > > PHC API, I think that would be the best approach. > > > > It's not. I am saying that to train the PHC to GPS time, we need to > > timestamp the GPS PPS with the PHC clock (so we can get the offset to > train > > the PHC). In the other thread (https://is.gd/qyYHDt) Richard had > suggested > > that this could be done by feeding GPS PPS into the NIC - IF the NIC was > > capable of timestamping external events like this. I was saying that some > > NICs can't do this, so it may be done elsewhere (like we do in our FPGA). > > What I don't understand is how is your FPGA different from a NIC. > In both cases there is a clock which is timestamping packets and PPS > on an input pin, right? The clock is provided by the system as a PHC > device. Why the PHC cannot support the PTP_EXTTS_REQUEST ioctl? > > -- > Miroslav Lichvar >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
