[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210323125134.GA29209@hoboy.vegasvil.org>
Date: Tue, 23 Mar 2021 05:51:34 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Dipen Patel <dipenp@...dia.com>, Arnd Bergmann <arnd@...db.de>,
Linus Walleij <linus.walleij@...aro.org>,
Kent Gibson <warthog618@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Jon Hunter <jonathanh@...dia.com>,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-tegra <linux-tegra@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Networking <netdev@...r.kernel.org>
Subject: Re: GTE - The hardware timestamping engine
On Tue, Mar 23, 2021 at 10:03:18AM +0100, Thierry Reding wrote:
> 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.
...
> 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.
It sounds like TKE + GTE together act like a PHC, and GTE doesn't
need/want its own SW interface.
Thanks,
Richard
Powered by blists - more mailing lists