Thanks for your help and recommendations.
You are very welcome.
We first tried on an Iris board and stock Toradex BSP image with a kernel compiled at the same revision than we have and could reproduce the error where the GPIO_INT_LVL register for port O was sometimes read incorrectly. I then updated to the latest BSP 2.7b2 kernel sources and the problem no longer appeared. Bisecting through the kernel commits, I isolated the fix to the commit apalis/colibri_t30: initialise tps65911 GPIOs.
The patch is not 100% clear to me and I’d like to better understand the changes to ensure that this commit definitely fixes our issues. Could you tell me a bit more on the TPS65911 GPIOs configuration and how the TPS65911 GPIO pins are connected to the Tegra. From the board-colibri_t30-power.c and tps6591x.c driver, it seems that the GPIO2 pin of the TPS65911 is connected to a “VDD_CORE enable” pin of the T30.
No, that is the enable pin of the TPS62362 PMIC providing the VDD CORE voltage.
Do you think that without this configuration we may have had some inconsistencies in the powering of the GPIO controller in sleep and so sometimes read inconsistent values ?
So you are saying you do use sleep modes and such? Of course even misbehaving DVFS could cause all sorts of such instabilities.
As as quick test, you can run the attached gpio-test.c program which programs GPIO port O GPIO_INT_LVL register with value 0x00888800 and then continuously reads this register.
I would really not recommend programming any GPIOs behind the Linux kernel’s back as this could have severe side effects especially together with DVFS and/or sleep modes.
We noticed that we executed this program in background and then launched a video playback with gst-launch we had wrong values read out of the register (0x00808800).
Hm, this could really point to misbehaving DVFS and/or idle/sleep mode. However it could also just be some sort of locking issue in regards to the Linux kernel vs. user space given that rather ugly approach.
Steps to reporoduce:
Colibri T30 IT module on Iris Carrier board
Kernel at commit before “apalis/colibri_t30: initialise tps65911 GPIOs”
On target configure GPIO pins O3 and O7 as GPIO inputs with GPIOTool
The GPIOTool is really also not meant for anything other than some interactive peaking and pocking. And “real” configuration should be done in the Linux kernel itself.
Compile and run gpio-test.c
Play a video with gst-launch
$ ./gpio-test & $ gst-launch filesrc -v location=/resources/Videos/turn_off_cycler.mp4 ! decodebin2 ! xvimagesink
Well, that one may be rather RAM buffer bound requiring careful locking.
Messages from gpio-test indicating read errors are displayed when the video is started:
Read register value changed: old = 0x00888800 new = 0x00808800
I still cannot fully explain what happens. Can you imagine a rational explanation given the effects we had and the patch which solved it ?
For me the whole test case really looks way too fishy. I suggest you trying a clean use case for proper validation thereof.