On Fri, Oct 26, 2018 at 04:54:57PM +0000, Keller, Jacob E wrote:
> > -----Original Message-----
> > From: Miroslav Lichvar [mailto:mlich...@redhat.com]
> > Sent: Friday, October 26, 2018 9:28 AM
> > To: netdev@vger.kernel.org
> > Cc: intel-wired-...@lists.osuosl.org; Richard Cochran
> > <richardcoch...@gmail.com>;
> > Keller, Jacob E <jacob.e.kel...@intel.com>; Miroslav Lichvar
> > <mlich...@redhat.com>
> > Subject: [RFC PATCH 4/4] ixgbe: add support for extended PHC gettime
> >
> > Cc: Richard Cochran <richardcoch...@gmail.com>
> > Cc: Jacob Keller <jacob.e.kel...@intel.com>
> > Signed-off-by: Miroslav Lichvar <mlich...@redhat.com>
> 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.
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.
Thanks,
--
Miroslav Lichvar
