I'll keep playing with it, but that didn't seem to help. For what its worth, the errors with hardware timestamping were present before I added a call to skb_timestamp_tx for software timestamping.
-- Matthew Via v...@matthewvia.info On Fri, Aug 9, 2019, at 12:16 PM, Keller, Jacob E wrote: > > -----Original Message----- > > From: Matthew Via [mailto:v...@matthewvia.info] > > Sent: Friday, August 09, 2019 8:48 AM > > To: Keller, Jacob E <jacob.e.kel...@intel.com>; > > linuxptp-users@lists.sourceforge.net > > Subject: Re: [Linuxptp-users] ptp4l with freescale dpaa2 ethernet > > > > I'll try patching that in -- does the flag need to be cleared in the TX > > confirmation > > function? > > > > > Oh! > > > > > > The driver must set the IN_PROGRESS flag somewhere: > > > > > > skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS; > > > > > > I don't see this in the code. It should probably be done in the > > > enable_tx_timestamp function. > > > > > Just to clarify what I think is happening: > > The dpaa2 driver doesn't set IN_PROGRESS. Because of this, the > skb_timestamp_tx function sets a software timestamp in the SKB. > > Due to this, the call to skb_timestamp_tx will loop the packet back to > the error queue of the socket. Upon seeing this packet, ptp4l will give > up and say that no hardware timestamp was provided. > > By the time that we call skb_hwtstamp_tx in the driver, ptp4l has > stopped polling since it already got one message. > > Thanks, > Jake > > _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
