> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Miroslav Lichvar > Sent: Monday, October 29, 2018 6:31 AM > To: Keller, Jacob E <[email protected]> > Cc: [email protected]; [email protected]; Richard Cochran > <[email protected]> > Subject: Re: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime > > On Fri, Oct 26, 2018 at 04:54:57PM +0000, Keller, Jacob E wrote: > > > -----Original Message----- > > > From: Miroslav Lichvar [mailto:[email protected]] > > > Sent: Friday, October 26, 2018 9:28 AM > > > To: [email protected] > > > Cc: [email protected]; Richard Cochran > <[email protected]>; > > > Keller, Jacob E <[email protected]>; Miroslav Lichvar > <[email protected]> > > > Subject: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime > > > > > > Cc: Richard Cochran <[email protected]> > > > Cc: Jacob Keller <[email protected]> > > > Signed-off-by: Miroslav Lichvar <[email protected]> > > > What about replacing gettime64 with: > > > > static int ixgbe_ptp_gettimex(struct ptp_clock_info *ptp, struct timespec64 > > *ts) > > { > > struct ptp_system_timestamp sts > > > > ixgbe_ptp_gettimex(ptp, &tst); > > *ts = sts.phc_ts > > } > > That will work, but it will be slower. With HPET as a clocksource > there would be few microseconds of an extra (symmetric) delay and the > applications would have to assume a larger maximum error. >
Right. My intention for this would be that we'd switch from gettime64 to gettime64x going forward, and provide this as a way to avoid having to duplicate logic in drivers while we're transitioning? Thus, new applications should be using the new call if it's available in the driver. Hmm. > I think there could be a flag in ptp_system_timestamp, or a parameter > of gettimex64(), which would enable/disable reading of the system > clock. > > > Actually, could that even just be provided by the PTP core if gettime64 > > isn't > implemented? This way new drivers only have to implement the new interface, > and > userspace will just get the old behavior if they use the old call? > > Good idea. Ideally we can find a way that minimizes the overhead for the old call. Thanks, Jake > > Thanks, > > -- > Miroslav Lichvar
