I maintain and use a homegrown GPIO library that at the low level opens a /dev/gpiochipN device node and issues ioctl() calls to manipulate the GPIO pins. At a higher level, GPIO pins are identified by a tuple of the chip number (the 0 in /dev/gpiochip0) and the line number. Each of the programming languages I use has a platform module with a table of tuple constants for the GPIO pins each platform offers. For the Raspberry Pi, until now, the chip number has always been zero for GPIO pins on the 40-pin expansion header. Other platforms such as the BeagleBone have multiple /dev/gpiochipN device nodes and so have tuples with chip numbers 0, 1, 2, etc.
I notice that with my custom kernel the Raspberry Pi 5 expansion header GPIO pins are now on /dev/gpiochip4. I have read some of the other threads regarding this API breaking change, and I am wondering what to do about it myself.
Is there some particular reason that they wound up on /dev/gpiochip4, and is there maybe a way to change the device tree to perhaps enumerate the multiple GPIO chips in an order that leaves the expansion header pins on /dev/gpiochip0? Is it even guaranteed to be /dev/gpiochip4 in the future?
I have tried patching pinctrl-rp1.c as suggested in one of the other discussion threads; it resulted in /sys/class/gpio/gpiochip0 indeed mapping to the expansion header, but still leaves /dev/gpiochip4 the corresponding device node. It also has the side effect of messing up SPI chip selects, which suggests device tree changes might not be very straightforward.
As I see it, I have a number of unpalatable alternatives:
I read in the other discussion threads that in the future GPIO pins will be identified even more dynamically, but surely there must remain some mechanism by which I can refer to expansion header pin number 37 as GPIO26?
I notice that with my custom kernel the Raspberry Pi 5 expansion header GPIO pins are now on /dev/gpiochip4. I have read some of the other threads regarding this API breaking change, and I am wondering what to do about it myself.
Is there some particular reason that they wound up on /dev/gpiochip4, and is there maybe a way to change the device tree to perhaps enumerate the multiple GPIO chips in an order that leaves the expansion header pins on /dev/gpiochip0? Is it even guaranteed to be /dev/gpiochip4 in the future?
I have tried patching pinctrl-rp1.c as suggested in one of the other discussion threads; it resulted in /sys/class/gpio/gpiochip0 indeed mapping to the expansion header, but still leaves /dev/gpiochip4 the corresponding device node. It also has the side effect of messing up SPI chip selects, which suggests device tree changes might not be very straightforward.
As I see it, I have a number of unpalatable alternatives:
- I can add new platform modules for the Raspberry Pi 5, something I have already done for the Orange Pi Zero 2 W.
- I can rewrite the platform modules, replacing the simple static tables they currently contain with mapping functions that figure all this out dynamically. Unfortunately, this would mean I can't have constants like RaspberryPi.GPIO26 anymore.
- I can delete /dev/gpiochip0 thru /dev/gpiochip3 and rename /dev/gpiochip4 to /dev/gpiochip0 at system startup IFF the target is a Raspberry Pi 5. This is a little kooky, but I tried it and it actually works.
- Add a udev or mdev event script does the device node shuffling as they are created in the first place.
- In my low level C code I can translate tuple (0,26) to (4,26) IFF the target is a Raspberry Pi 5. This would shield the higher level language platform modules from the API change.
I read in the other discussion threads that in the future GPIO pins will be identified even more dynamically, but surely there must remain some mechanism by which I can refer to expansion header pin number 37 as GPIO26?
Statistics: Posted by pmunts — Wed Jan 24, 2024 1:27 am