Bus access for gpiod

[Eugeny1]

Hello Bartosz, is there any way to organize GPIOs into bus? Instead of operating the bits per GPIO - organize, let's say, 8 GPIOs into the bus and pass 8-bit argument to the reading/writing calls? I can not find such functionality for gpiod as well as for ioctl access (however ioctl allows multiple lines). Does not sound elegant (and probably efficient?) splitting a bus into separate bits and pass 8 bytes for processing.

[brgl]

I've read that multiple times and I'm afraid I still have no idea what you mean exactly. Could you elaborate (preferably with examples)?

[Eugeny1]

Sure. I have microcontroller with 8-bit data bus attached to the GPIOs. I want to operate 8 bits a once, not splitting them onto bits when writing, making 8 ioctl calls (or one call with 8-byte array of values), and then assembling bits into the byte on reading. However, I gave it a thought and suspect that at our level of abstraction this may not make any sense because, of course, at some very low-level data is transferred using 32-bit words, but operating them will inevitably involve bit shifting/addressing operations, and they will not be contiguous if non-contiguous GPIO pins are selected. In addition, if you'd try to implement buses, you'd probably do the same as user program - splitting bits into bytes and pushing down the API... so may not have any benefit at all.

[brgl]

You can request and manipulate multiple lines at once from user-space using the kernel uAPI with libgpiod. However you seem to be talking about something that should go into the kernel driver for your GPIO controller.

[Eugeny1]

Hello Bartosz, thanks for your comments.

I have tried using the library with openwrt on Allwinner H3 platform, and the gpiod version fetched from the repository appeared to be relatively old not containing calls like searching for line using line name.

I was unable to figure out version of sources I have other than saying copyright -2018. Do you have any versioning in sources or in repository readme file?

This is the line from readme # SPDX-FileCopyrightText: 2017-2023 Bartosz Golaszewski <brgl@bgdev.pl> which is hardly the identification of the last modified / tested date for the whole solution (package) rather than for each individual file. (edit) was unable to find version information ins Makefiles too.

[Eugeny1]

I have another question to you as you are a master for the GPIO stuff for linux. I have bi-directional bus and must very frequently change direction of the GPIO. It is being done using GPIO_V2_LINE_SET_CONFIG_IOCTL - what are the conditions when this call may fail? This is critical for one vital reason - if GPIO will be stuck with ioctl failed to change the direction, not only whole communication will fail, but hardware may be potentially damaged by more than one device outputting signal onto the bi-directional lines. Therefore, before trying using this GPIO feature, this risk must be considered very closely. Please advise. Thanks!

[brgl]

Hello Bartosz, thanks for your comments.

I have tried using the library with openwrt on Allwinner H3 platform, and the gpiod version fetched from the repository appeared to be relatively old not containing calls like searching for line using line name.

I was unable to figure out version of sources I have other than saying copyright -2018. Do you have any versioning in sources or in repository readme file?

This is the line from readme # SPDX-FileCopyrightText: 2017-2023 Bartosz Golaszewski <brgl@bgdev.pl> which is hardly the identification of the last modified / tested date for the whole solution (package) rather than for each individual file. (edit) was unable to find version information ins Makefiles too.

Of course but just like the blurb for this repo states: this is just a mirror and the main repository is over at kernel.org. You'll find all the tags, stable branches and also a Changelog in the repo over there.

[brgl]

I have another question to you as you are a master for the GPIO stuff for linux. I have bi-directional bus and must very frequently change direction of the GPIO. It is being done using GPIO_V2_LINE_SET_CONFIG_IOCTL - what are the conditions when this call may fail? This is critical for one vital reason - if GPIO will be stuck with ioctl failed to change the direction, not only whole communication will fail, but hardware may be potentially damaged by more than one device outputting signal onto the bi-directional lines. Therefore, before trying using this GPIO feature, this risk must be considered very closely. Please advise. Thanks!

This question cannot really be answered easily. It may fail for a multitude of reasons. Most will have to do with the underlying kernel driver and the GPIOLIB abstraction layer on top of it. After all - as I already stated - libgpiod is a wrapper around the kernel uAPI. But it can fail for reasons completely unrelated to GPIO too - the kernel may run out of memory for one.

[Eugeny1]

Thanks. Another question please. It is obvious we need to release all the "software" resources before exiting/stopping using the GPIO, but what's about hardware state of them? How to properly "de-initialize" the GPIO pin? Should it be manual operation - e.g. set pin into input mode, clear the consumer string before closing its file handle?

[brgl]

This is driver-specific. Once you release the software handle for the GPIO, it's up to the driver to do whatever. It's not the user-space program's concern anymore.