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.
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
