> -----Original Message----- > From: Keller, Jacob E [mailto:jacob.e.kel...@intel.com] > Sent: Friday, August 09, 2019 8:31 AM > To: Matthew Via <v...@matthewvia.info>; linuxptp-users@lists.sourceforge.net > Subject: Re: [Linuxptp-users] ptp4l with freescale dpaa2 ethernet > > > -----Original Message----- > > From: Matthew Via [mailto:v...@matthewvia.info] > > Sent: Friday, August 09, 2019 8:07 AM > > To: linuxptp-users@lists.sourceforge.net > > Subject: [Linuxptp-users] ptp4l with freescale dpaa2 ethernet > > > > Hi, I am trying to get ptp4l working on an NXP Bluebox and the dpaa2 > > ethernet > driver. > > The kernel I'm using appears to have code for hardware timestamping in the > ethernet > > driver, though I needed to pull in patches from a more recent kernel to add > > support > > for ethtool to set the timestamping options. The relevent ethtool and > > dpaa2 drivers > > can be seen > > > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/freescale/dpaa2 > > /dpaa2-eth.c and > > > https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/freescale/dpaa2 > > /dpaa2-ethtool.c . > > > > ethtool -T eno0 shows: > > Time stamping parameters for eno0: > > Capabilities: > > hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) > > hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE) > > hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE) > > PTP Hardware Clock: 0 > > Hardware Transmit Timestamp Modes: > > off (HWTSTAMP_TX_OFF) > > on (HWTSTAMP_TX_ON) > > Hardware Receive Filter Modes: > > none (HWTSTAMP_FILTER_NONE) > > all (HWTSTAMP_FILTER_ALL) > > > > > > But when I fire up ptp4l with `ptp4l -i eno0 -H -m`, I get: > > This is requesting hardware timestamping. > > > ptp4l[516.260]: selected /dev/ptp0 as PTP clock > > ptp4l[516.271]: driver changed our HWTSTAMP options > > ptp4l[516.271]: tx_type 1 not 1 > > ptp4l[516.271]: rx_filter 1 not 12 > > ptp4l[516.271]: port 1: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[516.271]: port 0: INITIALIZING to LISTENING on INITIALIZE > > ptp4l[522.612]: port 1: LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[522.612]: selected best master clock 00049f.fffe.052fee > > ptp4l[522.612]: assuming the grand master role > > ptp4l[523.613]: timed out while polling for tx timestamp > > ptp4l[523.614]: increasing tx_timestamp_timeout may correct this issue, but > > it is > > likely caused by a driver bug > > ptp4l[523.614]: port 1: send sync failed > > ptp4l[523.615]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > ptp4l[539.634]: driver changed our HWTSTAMP options > > ptp4l[539.634]: tx_type 1 not 1 > > ptp4l[539.635]: rx_filter 1 not 12 > > ptp4l[539.635]: port 1: FAULTY to LISTENING on FAULT_CLEARED > > ptp4l[546.345]: port 1: LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > ptp4l[546.346]: selected best master clock 00049f.fffe.052fee > > ptp4l[546.346]: assuming the grand master role > > ptp4l[547.347]: timed out while polling for tx timestamp > > ptp4l[547.347]: increasing tx_timestamp_timeout may correct this issue, but > > it is > > likely caused by a driver bug > > This usually indicates the driver is not sending the Tx timestamp back to the > stack, > especially if you increase it past a few milliseconds. > > > ptp4l[547.348]: port 1: send sync failed > > ptp4l[547.348]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) > > ptp4l[563.367]: driver changed our HWTSTAMP options > > ptp4l[563.367]: tx_type 1 not 1 > > ptp4l[563.367]: rx_filter 1 not 12 > > ptp4l[563.367]: port 1: FAULTY to LISTENING on FAULT_CLEARED > > ptp4l[569.932]: port 1: LISTENING to MASTER on > > ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES > > > > > > Everything I've read suggests that this is usually the driver not using > > skb_tstamp_tx > in > > the right place, or in a buggy manner -- I've tried increasing the timeout > > to over > 1000 > > ms, and that had no effect. This happens consistently for each packet > > though. I > > added a netdev_info call in dpaa2-eth.c where it calls skb_tstamp_tx and I > > consistently get good looking timestamps each time ptp4l tries to send. > > Does > anyone > > have any idea what might not be working here? > > But skb_tstamp_tx is for software timestamping, if I recall correctly. >
I didn't. This is the correct function to call for reporting a Tx timestamp. The software timestamping function is skb_tx_timestamp(skb) Hmm, Jake > > > > Additionally, I added a skb_tx_timestamp call in the transmit path and the > > relevent > > software timestamping flags to the ethtool interface in the hopes that I > > could at > least > > use software timestamping, and I get the exact same output from ptp4l as > > above > > (with the -S option). > > > > If anyone has any guidance on how to getting either hardware or software > > timestamping working, I would appreciate it. > > Try using the software timestamping option for ptp4l, and see if that works > first. > (Should be -S) > > Thanks, > Jake > > > > > Thanks, Matthew > > -- > > Matthew Via > > v...@matthewvia.info > > > > > > _______________________________________________ > > Linuxptp-users mailing list > > Linuxptp-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
