On Tue, 23 Mar 2021 10:06:39 +0000,
Thierry Reding [off-list ref] 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.