GTE on linux: duplicated event on GPIO rising edge

Sorry for the late response, have you managed to get issue resolved or still need the support? Thanks

Hi @kayccc ,
The issue is still open from our end. Thanks for checking.

What’s the lic_irq you are using when you PZ.04 as input and PZ.05 as output?

Hi @KevinFFF,

Thanks a lot for following up on this thread.

I’m using the value from the macro TEGRA234_IRQ_GPIO1_0 defined in soc/t23x/kernel-include/dt-bindings/interrupt/tegra234-irq.h, so 296.

Regards.

Could you help to provide the full dmesg after you run the test?

Hi @KevinFFF,

Sure, find the dump attached. I annotated it with the commands I ran around the relevant sections.
dmesg.txt (59.6 KB)

I also tried adding debounce time on the input GPIO (as suggested in this other ticket I submitted: SPE: GTE provided TSC sometimes goes backwards - #13 by maxe777), but I get the same behavior.

Looking forward to the outcome of your tests.

Hi @KevinFFF,

What is the status on your side? Could you reproduce the issue?

Regards

Hi @KevinFFF,

friendly reminder, this ticket is still pending an answer. Thank you.

Sorry for the late reply, I’ve referred your steps and could reproduce the same behavior as yours.

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.

When you did this, could you still see any interrupt?

How do you know this is coming from your setup?
Have you tried to disable tegra-hsp@c150000 in device tree?

Hi @KevinFFF

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?

Thank you

Hi @KevinFFF,

Would you have an update on this ticket? Thanks.

Hi @KevinFFF,

Any status update from your side? Thanks

Hi @KevinFFF,
Still no update from your side?

Sorry that I’ve been occupied by other tasks and will look into this issue next week.

Gentle bump up

Leaving a note to indicate that this ticket is still pending resolution and avoiding the auto-close

Same note as usual. @KevinFFF, would you have an update to share? Thanks.

Could you try to verify with the latest R35.4.1 and R36.2 to check if you still could reproduce the issue?

Good point @KevinFFF. I will try on 35.4.1 and report the status.

1 Like

I still need to try, I will report here the outcome.