Mangoh Red GPIOExpander

mangOH Red
2

It’s complicated…

The SX1509 GPIO expander is an I2C device attached to the I2C bus of the mangOH Red.

The legato app GpioService provides a Legato API (le_gpio.api) that allows Legato apps to control GPIOs. Internally this is implemented using the sysfs facilities provided by gpiolib in the Linux kernel.

There is a Linux kernel driver that supports the SX1509 so it should be possible to register the SX1509 as a gpiochip into the kernel. There are two main problems with this.

  1. The Legato GpioService has a static list of GPIOs that it supports. So if we dynamically add more, they don’t automatically become supported by the GpioService. This could probably be worked around by having a MangohRedGpioService that re-uses some of the components of GpioService.
  2. Sierra Wireless made modifications to gpiolib in the Linux kernel. The idea was to provide an abstraction between the GPIO numbers that users are familiar with based on the labels of the WP module pins and the internal GPIO numbers. For example, on the WP76 the pin labeled “GPIO32” in the WP schematic is actually GPIO 77 inside the Linux kernel. This mapping table is represented in the ext_gpio_wp array in drivers/gpio/gpiolib-sysfs.c in the WP76 kernel. There are many problems with this approach, but the one that is relevant here is that this is a compile-time table. So when the SX1509 driver dynamically registers a new gpiochip, there is no entry added into the table. So if you do echo 801 > /sys/class/gpio/export (assuming 801 is a GPIO on the sx1509) you will get an error because there is no entry in the lookup table for 801.

I reported this issue a long time ago internally within Sierra Wireless, but so far no work has been done to address this design flaw. I provided a suggestion which was to create functions to register/deregister aliases. So then we could present /sys/class/gpio/aliases/WP_GPIO32 which when read would return “77”.

Because of the issue with using the kernel driver with the Sierra Wireless kernel, we created the GpioExpanderServiceRed app. This app is basically a userspace i2c driver for the sx1509. If you don’t care about controlling the GPIOs from inside the kernel or from the Linux command line, then this approach works fine.

The problem now is that we do care about controlling the GPIOs of the expander from within the kernel. There’s an IoT slot kernel module which needs to manipulate the GPIO expander to provide access to relevant hardware. For example, GPIO expander GPIO 9 controls SDIO_SEL which must be manipulated to provide SDIO access to the IoT slot.

So the sum things up:

  • If you want the IoT slot driver and control over the GPIO expander from userspace you are out of luck.
  • If you want the IoT slot driver, but no access to the GPIO expander from userspace then you don’t need to do anything. This is the way the mangOH_Red.sdef is setup today.
  • If you don’t need the IoT slot driver, but want access to the GPIO expander from userspace, then you need to comment out the code in the mangoh red kernel module which instantiates the sx1509 device, the iot slot device and the mux functionality that is passed to the iot slot device.