On Tue, 23 Mar 2021 10:06:39 +0000, Thierry Reding <thierry.reding@xxxxxxxxx> 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.
