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
