pmunts
Posts: 18
Joined: Fri Nov 08, 2013 7:19 pm

Raspberry Pi 5 gpiochip4

Wed Jan 24, 2024 1:27 am

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 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?

pmunts
Posts: 18
Joined: Fri Nov 08, 2013 7:19 pm

Re: Raspberry Pi 5 gpiochip4

Thu Jan 25, 2024 6:52 pm

I wound up solving this problem with a fix described in http://git.munts.com/muntsos/doc/AppNot ... iochip.pdf.

cleverca22
Posts: 8831
Joined: Sat Aug 18, 2012 2:33 pm

Re: Raspberry Pi 5 gpiochip4

Thu Jan 25, 2024 11:01 pm

related, i noticed some other weirdness when making a table of every gpio

the bcm2712 has 2 gpio controllers, each with 2 banks of pins
the driver exposes each bank as its own gpiochip

the rp1 has a single gpio controller, with 3 banks of pins
its driver exposes everything as a single gpiochip!

pidloop
Posts: 24
Joined: Fri Jul 12, 2019 7:41 pm

Re: Raspberry Pi 5 gpiochip4

Thu Feb 22, 2024 5:58 am

This thread helped me straighten this out, thanks.

There’s no reason it couldn’t have stayed gpiochip0. What a mess they’ve made.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16130
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspberry Pi 5 gpiochip4

Thu Feb 22, 2024 3:53 pm

gpiochip numbers are assigned purely by the GPIO framework at https://elixir.bootlin.com/linux/latest ... lib.c#L848.
There is no way for a driver to influence the number it is assigned, it is purely down to probe order.

As RP1 is on a PCIe bus it will almost always enumerate after directly connected peripherals, therefore it gets a higher number.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cleverca22
Posts: 8831
Joined: Sat Aug 18, 2012 2:33 pm

Re: Raspberry Pi 5 gpiochip4

Thu Feb 22, 2024 3:58 pm

6by9 wrote:
Thu Feb 22, 2024 3:53 pm
gpiochip numbers are assigned purely by the GPIO framework at https://elixir.bootlin.com/linux/latest ... lib.c#L848.
There is no way for a driver to influence the number it is assigned, it is purely down to probe order.

As RP1 is on a PCIe bus it will almost always enumerate after directly connected peripherals, therefore it gets a higher number.
but i seem to remember spi/ttyama/i2c used to behave similarly?
and then things where changed to make the naming more predictable

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16130
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspberry Pi 5 gpiochip4

Thu Feb 22, 2024 4:07 pm

cleverca22 wrote:
Thu Feb 22, 2024 3:58 pm
but i seem to remember spi/ttyama/i2c used to behave similarly?
and then things where changed to make the naming more predictable
For both I2C and SPI those were mainline changes
I2C - https://github.com/torvalds/linux/commi ... b32c5692c7
SPI - https://github.com/torvalds/linux/commi ... bb508c2408
Pass on tty - I'm not searching for it.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cleverca22
Posts: 8831
Joined: Sat Aug 18, 2012 2:33 pm

Re: Raspberry Pi 5 gpiochip4

Thu Feb 22, 2024 4:27 pm

ah, i wasnt sure who initiated the changes

Return to “Interfacing (DSI, CSI, I2C, etc.)”