Re: [Linuxptp-devel] [PATCH v4] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Keller, Jacob E
> -Original Message- > From: Petr Machata [mailto:pe...@mellanox.com] > Sent: Tuesday, June 11, 2019 9:35 AM > To: linuxptp-devel@lists.sourceforge.net > Cc: Petr Machata ; Keller, Jacob E > ; Geva, Erez > Subject: [PATCH v4] sk: Recognize HWTSTAMP_FILTER_SOME > > struct

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Keller, Jacob E
> -Original Message- > From: Geva, Erez [mailto:erez.geva@siemens.com] > Sent: Tuesday, June 11, 2019 7:32 AM > To: Petr Machata > Cc: linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME > > If you ask to stamp all

[Linuxptp-devel] [PATCH v4] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Petr Machata
struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all requested packets will be timestamped, and some others as well. Update hwts_init() to recognize this as a valid response in HWTS_FILTER_NORMAL

Re: [Linuxptp-devel] [PATCH v3] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Petr Machata
Geva, Erez writes: > It make sense for HWTS_FILTER_NORMAL. > > But for HWTSTAMP_FILTER_ALL, it does not make sense to get > HWTSTAMP_FILTER_SOME. > Some of what? You ask for all! Yeah, there isn't really anything besides ALL thas this could timestamp. I'll just modify the HWTS_FILTER_NORMAL

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Geva, Erez
If you ask to stamp all packets with HWTSTAMP_FILTER_ALL, then you can not get a reply of "plus some others". You ask for all, which more do you think you can get? It does make sense as a reply in case of HWTS_FILTER_FULL. enum hwtstamp_rx_filters { /* time stamp any incoming packet */

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Richard Hill
Hello Sanjay. “Richard had suggested that this could be done by feeding GPS PPS into the NIC” I have modified the FEC driver for iMX6 to bring in the GPS-PPS. I’m able to track GPS by +/- 25ns (given that the GPS receiver is only that stable) Using a modified version of phy2sys to keep

Re: [Linuxptp-devel] [PATCH v3] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Geva, Erez
Hi, It make sense for HWTS_FILTER_NORMAL. But for HWTSTAMP_FILTER_ALL, it does not make sense to get HWTSTAMP_FILTER_SOME. Some of what? You ask for all! Neither can you use rx_filter in this case, since it was not used in the SIOCSHWTSTAMP request. Erez

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Petr Machata
Geva, Erez writes: > Hi, > > The "cfg.rx_filter != HWTSTAMP_FILTER_ALL)) { " > line catch both filter mode is "HWTS_FILTER_FULL, and the fact that the > filter could is in a higher state for both HWTS_FILTER_NORMAL, > HWTS_FILTER_CHECK. > > Could you be more specific what does the

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Miroslav Lichvar
On Tue, Jun 11, 2019 at 09:44:32AM -0400, Sanjay Bhandari wrote: > > 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

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Sanjay Bhandari
> 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

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Miroslav Lichvar
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

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Sanjay Bhandari
> 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

[Linuxptp-devel] [PATCH v3] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Petr Machata
struct hwtstamp_config.rx_filter passed to SIOCSHWTSTAMP can be updated by the kernel with the value of HWTSTAMP_FILTER_SOME. That indicates that all requested packets will be timestamped, and some others as well. Update hwts_init() to recognize this as a valid response, instead of rejecting it

Re: [Linuxptp-devel] support for chrony like refclock SOCK

2019-06-11 Thread Miroslav Lichvar
On Mon, Jun 10, 2019 at 08:17:05AM -0400, Sanjay Bhandari wrote: > Has it been considered adding a chrony like refclock SOCK interface ( > https://is.gd/skln7i) to either ptp4l or phc2sys, where samples could be > fed from an external source like the GPS (or other) to set the PHC? What > are the

Re: [Linuxptp-devel] [PATCH v2] sk: Recognize HWTSTAMP_FILTER_SOME

2019-06-11 Thread Geva, Erez
Hi, The "cfg.rx_filter != HWTSTAMP_FILTER_ALL)) { " line catch both filter mode is "HWTS_FILTER_FULL, and the fact that the filter could is in a higher state for both HWTS_FILTER_NORMAL, HWTS_FILTER_CHECK. Could you be more specific what does the HWTSTAMP_FILTER_SOME means? For me, the