Re: GTE - The hardware timestamping engine

From: Marc Zyngier <maz@kernel.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Dipen Patel <dipenp@nvidia.com>,
	Kent Gibson <warthog618@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnd Bergmann <arnd@arndb.de>,
	Richard Cochran <richardcochran@gmail.com>
Subject: Re: GTE - The hardware timestamping engine
Date: Tue, 23 Mar 2021 18:21:09 +0000	[thread overview]
Message-ID: <87h7l1k9yi.wl-maz@kernel.org> (raw)
In-Reply-To: <YFm9r/tFkzVlYDEp@orome.fritz.box>

On Tue, 23 Mar 2021 10:06:39 +0000,
Thierry Reding <thierry.reding@gmail.com> wrote:

[...]

> Obviously if we don't integrate this with IRQs directly, it becomes a
> bit more difficult to relate the captured timestamps to the events
> across subsystem boundaries. I'm not sure how this would be solved
> properly. If the events are sufficiently rare, and it's certain that
> none will be missed, then it should be possible to just pull a timestamp
> from the timestamp FIFO for each event.
> 
> All of that said, I wonder if perhaps hierarchical IRQ domains can
> somehow be used for this. We did something similar on Tegra not too long
> ago for wake events, which are basically IRQs exposed by a parent IRQ
> chip that allows waking up from system sleep. There are some
> similarities between that and GTE in that the wake events also map to a
> subset of GPIOs and IRQs and provide additional functionalities on top.
> 
> I managed to mess up the implementation and Marc stepped in to clean
> things up, so Cc'ing him since he's clearly more familiar with the topic
> than I am.

Sure, but I'm pretty clueless when it comes to what this GTE thing
does (it has a fast car ring to it, which isn't a selling point for
me... ;-).

If, as I understand it, it is supposed to collect timestamps on
signalling of IRQs, you could make it part of the kernel's view of the
interrupt path by "pushing" a domain on top of the IRQ stack,
triggering the configuration/timestamping of this interrupt.

What is completely unclear to me is how you extract information from
it. The IRQ doesn't really give you an interface to extract a lot of
information aside from an interrupt count and what is defined as the
interrupt state. A timestamp doesn't really count as state, so you'd
need to invent something new here.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.