I made some tests with the GTE on linux side to stamp the rising edge of a GPIO.
I’m facing an unclear situation: I’m getting 2 timestamps out of the GTE for each rising edge, while a single one would be expected. I’m most likely overlooking something.
Jetson Orin Nano 4GB module
Custom carrier board
Jetpack 5.1.1 / L4T 35.3.1
timestamp the rising edge of a GPIO with the GTE on the linux side.
since I’m already using the AON GTE on the SPE, I need to rely on the LIC GTE.
I’m aware that using the LIC GTE means that interrupts of a given GPIO controller are aggregated.
I based my test on the tegra194_gte_test kernel module as provided by nvidia
my input GPIO is Z.04 (given as parameter to the kernel module as gpio_in=482), managed by the GPIO controller 1
my output GPIO is Z.05 (given as parameter to the kernel module as gpio_out=483)
the gpio line is driven as expected (I checked with the scope)
On the rising edge, the interrupt triggers - I can see the print
In the “store_gpio_en_dis” function registering the event to the GTE:
I updated the GTE engine to be used from the AON to the LIC one
I updated the argument to “tegra_gte_register_event” to use the IRQ TEGRA234_IRQ_GPIO1_0 (value 296)
I do get the expected prints on the rising edge: “GPIO HW Timestamp: raw 698048997994, ns 22337567935808”
However, the interval between the timestamps are not the expected ones. When the GPIO toggles every 5s (so one timestamp is expected every10s), I got the following intervals (scaled in seconds for readability):
By checking a bit more, I realized that from the ISR I can always get 2 successful calls to “tegra_gte_retrieve_event”.
I first suspected that I was getting the interrupt from another pin in the same GPIO controller. But I could not find any based on the report from /proc/interrupts. Among all listed gpios, only GPIO 134 (so PZ.04) is reports interrupts.
To be 100% sure that the events are only linked to the GPIO Z04, I moved the “tegra_gte_retrieve_event” in the timer callback, and edited the register GPIO_Z_ENABLE_CONFIG_04_0 to toggle the bit 6 (INTERRUPT_FUNCTION) while the kernel module was loaded:
devmem2 0x02211480 b 0x19 # Interrupt bit disabled, no more HW timestamp are available
devmem2 0x02211480 b 0x59 # Interrupt bit enabled, HW timestamp are available (but 2 of them coming at once)
When the setup is running with HW timestamps, I found 2 entries in /proc/interrupts matching the expected pace:
GICv3 165 Level c150000.tegra-hsp
gpio 134 Edge tegra_gte_test_isr
The second one is the one I expect. I’m not sure how the HSP part comes into the picture and why this would generate an extra event matching my GTE event descriptor.
Any suggestion about how to investigate this further would be appreciated. Thank you.
I’ve referred your steps and could reproduce the same behavior as yours
Thank you so much, this is great news.
It seems this patch removing 2 nodes(lic_irq_en_dis, lic_irq_ts) under /sys/kernel/tegra_gte_test/ and use gte-lic instead of gte-aon.
Correct. As stated in the initial post, since gte-aon is already used by the SPE in my setup, using gte-lic is the goal to get GTE support on the CCPLEX side.
When you did this (devmem2 0x02211480 b 0x19), could you still see any interrupt?
I checked carefully again the output of /proc/interrupts:
when the IN out OUT gpios are connected together, “gpio 134 Edge tegra_gte_test_isr” fires at the expected rate, and increments exactly by 1 when I see the rising egde on the scope; But the ISR from the driver reports 2 timestamps in a short interval (the GTE stamps are spaced by about 11us), for a GPIO rising edge every 10s.
when the IN out OUT gpios are connected together, and the devmem command to disable the interrupt function was run, the same entry under /proc/interrupts no longer increments on the rising edge (and the driver ISR no longer fires). Setting the register value back to 0x59 restores the initial behavior.
when IN and OUT gpios are not connected together, the gpio 134 entry under /proc/interrupt stays stable and the driver gets no ISR (same behavior as when the interrupt gets disabled with devmem).
How do you know this is coming from your setup?
This actually seems to be unrelated. I could actually only catch activity on 3c00000.tegra-hsp this time, and I cannot relate this interrupt activity to the GPIO activity.
I also attached the diff of /proc/interrupts from dumps before and after I can see a rising edge on the scope to give you the overview: int_diff.txt (1.8 KB)
Could you please advise what else can be checked to figure out what is reason behind this extra entry under the GTE?