GPIO Interrupts on WP7702 Module

mangOH Red
1

I am working on getting edge detected GPIO interrupts working on a WP7702 module. This would be inside a Linux kernel driver. Loading the module I have written had no luck. So, I’ve been trying to step through it in user space first, also with no luck.

At the suggestion of the previous post on the forum ((Cross post) Detecting edges on SysFS pins by @dfrey ) I switched from my initial attempt at GPIO22 (which is available on the Raspberry Pi header) to GPIO36. However, when attempting the “at+wiocfg=36,16”, I discovered that it appears that GPIO36 is not present on a WP7702 module? Output from at+wiocfg? is:
at+wiocfg?
+WIOCFG: 2,16,0,0,1,0,0
+WIOCFG: 6,0,0,0,1,0,0
+WIOCFG: 7,16,0,0,1,0,0
+WIOCFG: 8,16,0,0,1,0,0
+WIOCFG: 13,16,0,0,1,0,0
+WIOCFG: 21,16,0,0,1,0,0
+WIOCFG: 22,16,0,0,3,4,0
+WIOCFG: 23,16,0,0,1,0,0
+WIOCFG: 24,16,0,0,1,0,0
+WIOCFG: 25,16,0,0,1,0,0
+WIOCFG: 28,16,0,0,1,0,0
+WIOCFG: 29,16,0,0,1,0,0
+WIOCFG: 30,16,0,0,1,0,0
+WIOCFG: 31,16,0,0,1,0,0
+WIOCFG: 32,16,0,0,1,0,0
+WIOCFG: 33,16,0,0,1,0,0
+WIOCFG: 35,16,0,0,1,0,0
+WIOCFG: 42,16,0,0,1,0,0

OK

Note that GPIO36 is not present. Doing “at+wiocfg=36,16” results in an error.

You’ll notice from the above output that I tried allocating GPIO22 to the CF3 module, configuring it with a pull-up, and edge triggered on the falling edge. Grounding the pin (or tying it to +3.3volts - this is on the Raspberry Pi header so that’s safe) does not result in the “at!gpioint” unsolicited notification.

I guess I have three questions: 1) Have I screwed this up somehow? Code for the (very short) kernel driver is here: https://gitlab.bigw.org/fgodfrey/arduino_i2c_keyboard (yes, I know I can’t printk() from an interrupt, but that’ll work fine for testing). 2) Did I correctly interpret the previous forum post on this subject correctly that only GPIO’s 36, 38 and 39 can trigger an actual Linux interrupt? 3) If I have done this all correctly, is there any way to do asynchronous I/O on the WP7702 with a MangOH Red?

2

If anyone else stumbles across this… I figured out my issue. It turns out that Sierra Wireless goes to great lengths to hide Linux’s idea of the “real” GPIO number from you. This is “great” if you’re in user space since the GPIO on the schematic matches the number in Linux’s sysfs interface. Unfortunately, if you’re in the kernel, this doesn’t work at all; you need to request the real GPIO number. My hint was when I hit one of the “wakeup” pins (GPIO36) and the message printed to the console talked about GPIO26, not 36. Much code tracing later, I finally found the mapping!

If you are looking to do something like this, the mapping is located in the kernel source. Not sure if there’s an easier way, but I had it as a byproduct of building Yocto so assuming you did what I did, the mapping is located in:
yocto/build_bin/tmp/work/swi_mdm9x28-poky-linux-gnueabi/linux-quic/3.18.20+gitdd8fe1c7affdfb324e1b5db7701dbb69af46a8ec-r1/build/source/drivers/gpio/gpiolib-sysfs.c

Open that file in your favorite editor and look for the table called “ext_gpio_wp”. The first column is the schematic GPIO number which will also appear in /sys/class/gpio/… (and presumably, Legato). The second column is the “real” Linux GPIO number, which is what you need to use to call, say, gpio_reserve() or gpio_to_irq().

@dfrey - would it be possible to get this documented someplace other than the one C file? (Or is it already and I just missed it?) It doesn’t seem to be in the SIerra manual for the module and it also doesn’t seem to be in the mangOH docs. I realize this is more a core Sierra issue than a mangOH one, but anyone on this platform trying to write a GPIO kernel module will likely be interested.

1 Like
3

Hi @fgodfrey,

The hardcoded gpiolib table has been a big problem for mangOH for a long time. Unfortunately, my numerous complaints about this issue haven’t had the desired effect. If you have any other contacts in Sierra, I encourage you to reach out to them and tell them that the gpiolib implementation is a problem and caused you to lose time.

1 Like
4

Alas, this is a one-off “hobby” type project for me (I’m a professional developer, just not in this industry) so I don’t have any contacts. However, I’ll give it a whirl over on the Sierra forums and see what happens. At a bare minimum, it should be documented in their manual…
Thanks!

5

HI fgodfrey,
Thanks for sharing this information. That saved me from some heartache. I would like to add that these files in in kernel/drivers directory and copied to the build directory.
Srinivas