Can SODIMM 184 be used as a GPIO in the Colibri iMX6DL?

[MikeS]

@alex.tx I’m using WinCE image 1.8 and BSP version 2.6

I think I’ve found the root cause. I found that pin 184 behaves perfectly well if I set it or clear it using the GPIOconfig tool without having my firmware running. That made me believe that pin 184 can be used as a GPIO in the Colibri iMX6DL, as you just confirmed in your last message.

On a hunch I wondered if the GPIO library is not thread-safe so I added a mutex to protect calls to Gpio_SetLevel() and Gpio_GetLevel(). Our firmware only sets and clears pin 184 from a single thread, but we have other threads which use other GPIO pins at the same time. Adding a mutex appears to solve the problem, but I need to perform a longer-term test to confirm that the problem is really solved. I’m concerned about the performance impact of having to use a mutex, although I have not yet measured what that impact might be.

After testing the addition of a mutex I found this relevant post, which contains a comment from you saying that the GPIO library is thread-safe on the T20 but not on the iMX6. That would explain why we don’t see this issue when we use a T20 on the same carrier board running the same firmware, but we do see this issue now that we are migrating to the iMX6.

Multi threaded applications using new Libraries

The interrupt library is thread safe on all modules. The i2c library is not thread safe on all modules. The Gpio library is thread safe on the T20 and T30 modules. The Tegra CPUs provide atomic bit-set and bit-clear registers for the GPIO peripherals. To make the Gpio library thread safe on all modules, we needed to protect each GPIO operation with a mutex, which would have huge impacts on performance. Therefore we decided to avoid the mutex and implement as much thread safety as possible, …

I have a few questions:

1. Is Gpio_GetLevel() thread-safe? My guess is that the non-atomic process is setting and clearing a bit in the GPIO control register, which would mean that reading a bit from that register is safe to do. I am currently running an experiment where I only use a mutex to protect Gpio_SetLevel() and that seems to suggest that Gpio_GetLevel() does not need to be protected.
2. I’m guessing that the problem only occurs when accessing GPIO pins in the same GPIO bank from different threads. If that is true then it might be more efficient to use a set of mutexes to protect access to the banks individually, rather than using a global GPIO mutex. Is my guess right?
3. If I should protect GPIO banks individually then could you share a link to a document which maps SODIMM pin numbers to GPIO bank numbers? I’m sure I have seen a document like that on the Toradex web site but I can’t find it now.
4. We also use the iMX6 with Torizon. It sounds like the non-atomic behavior is a hardware register issue, in which case the Torizon GPIO driver must have the same issue. Is the GPIO driver on Torizon also not thread-safe, or does Linux already add a mutex to protect us?
5. On the iMX6 we can use any GPIO as the chip select with the SPI driver. That makes me think that on the iMX6 the Spi_Read() function uses Gpio_SetLevel() internally. Is that true? If it is then I would need to protect my calls to Spi_Read() with the same mutex that I use to protect Gpio_SetLevel()