Re: GTE - The hardware timestamping engine

[Thierry Reding]

On Mon, Mar 22, 2021 at 01:33:38PM -0700, Dipen Patel wrote:
> Hi Richard,
> 
> Thanks for your input and time. Please see below follow up.
> 
> On 3/20/21 8:38 AM, Richard Cochran wrote:
> > On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote:
> >> Adding Richard Cochran as well, for drivers/ptp/, he may be able to
> >> identify whether this should be integrated into that framework in some
> >> form.
> > 
> > I'm not familiar with the GTE, but it sounds like it is a (free
> > running?) clock with time stamping inputs.  If so, then it could
> > expose a PHC.  That gets you functionality:
> > 
> > - clock_gettime() and friends
> > - comparison ioctl between GTE clock and CLOCK_REALTIME
> > - time stamping channels with programmable input selection
> > 
> GTE gets or rather records the timestamps from the TSC
> (timestamp system coutner) so its not attached to GTE as any
> one can access TSC, so not sure if we really need to implement PHC
> and/or clock_* and friends for the GTE. I believe burden to find correlation
> between various clock domains should be on the clients, consider below
> example.

I agree. My understanding is the the TSC is basically an SoC-wide clock
that can be (and is) used by several hardware blocks. There's an
interface for software to read out the value, but it's part of a block
called TKE (time-keeping engine, if I recall correctly) that implements
various clock sources and watchdog functionality.

As a matter of fact, I recall typing up a driver for that at some point
but I don't recall if I ever sent it out or what became of it. I can't
find it upstream at least.

Anyway, I think given that the GTE doesn't provide that clock itself but
rather just a means of taking a snapshot of that clock and stamping
certain events with that, it makes more sense to provide that clock from
the TKE driver.

Thierry

Attachment: signature.asc
Description: PGP signature