Re: [questions] : gpiolib and gpioset behaviour

[Kent Gibson <warthog618@xxxxxxxxx>]

On Mon, Apr 22, 2024 at 06:49:05PM +0200, Gilles BULOZ wrote:
> On Mon, Apr 22, 2024 at 3:55 PM Bartosz Golaszewski wrote :
> > On Mon, Apr 22, 2024 at 2:44 PM Gilles BULOZ <gilles.buloz@xxxxxxxxxxx> wrote:
> >>
> >> Hi Bartosz,
> >>
> >> Several years after our discussions about GPIOs, some things are still unclear
> >> to me.
> >>
> >> 1 - The gpioset command has this in its help : "Note: the state of a GPIO line
> >> controlled over the character device reverts to default when the last process
> >> referencing the file descriptor representing the device file exits. This means
> >> that it's wrong to run gpioset, have it exit and expect the line to continue
> >> being driven high or low. It may happen if given pin is floating but it must
> >> be interpreted as undefined behavior." But up to now I've never seen such
> >> behaviour and I'm glad to have the GPIO set by gpioset keep their state once
> >> the command exits. Is reverting to default an optional behaviour in the GPIO
> >> chip driver, or in the gpiolib stack ?
> >>
> >
> > This behavior is driver-specific. Meaning: you're in-kernel GPIO
> > driver may actually retain the state.
> >
>
> Which method should the driver implement to restore the state on GPIO when the
> last process referencing the character device exits ?
>
> >> 2 - I've recently wrote a GPIO driver for an I2C FPGA design having ~112 GPIOs
> >> and wanted to use get_multiple() and set_multiple to have more efficent
> >> accesses, but realized that the line number was limited to 63 because of the
> >> unsigned long mask/bits. But I've noticed that working on a line number >= 64
> >> was unexpectedly calling these methods with a mask at 0 instead of calling
> >> get/set methods, and that the only way to have things working was to not
> >> define get_multiple/set_multiple but only get/set. Is it the expected
> >> behaviour ?
> >> At the end I've split the GPIOs into two banks (first with 64 and second with
> >> 48 GPIOs) to be able to use get_multiple/set_multiple.
> >>
> >
> > Please use libgpiod v2. That won't help you with the max requested
> > line limit but at least it's more modern API and actively developed.
> >
>

I suspect you are referring to gpiolib here - the mask in gc->get_multiple()
being unsigned long*.

The uAPI that libgpiod uses is limited to 64 lines per request, but that is
only relevant if you want to request more than 64 lines at once from userspace
(you would have to break that into two requests to access all 112 lines).

Note that the mask in gc->get_multiple() is unsigned long*, so it is a
pointer to an array of unsigned long.  Its width is not limited by
unsigned long, but by the bits parameter.  In your case the mask you pass
should contain multiple unsigned longs to achieve 112 bits.
Refer to gpiod_get_array_value_complex() for an example of building bitmap
masks to pass to gc->get_multiple(), in that case via
gpio_chip_get_multiple().

> OK
>
> >> 3 - Is there some way to request a GPIO already owned by another process as
> >> input or output, just to get the current level on the input or the level
> >> driven on output ? This would be much more efficient for real-time
> >> applications than asking the owner such information.
> >>
> >
> > Ha! Please help me help you. Take a look at the DBus daemon I recently
> > posted[1]. With the daemon running, the behavior will be exactly what
> > you expect. You'll be able to get/set values and have the command-line
> > tool exit while the daemon retains the state.
> >
>
> I was thinking about some specific "watcher" ioctl to do so, not a DBus
> daemon because this is not welcome in the real-time and embedded world.
> The only workaround I've found is to directly read the GPIO chip registers
> but this is bad to do so.
>

No there isn't, and I can't say I'm a fan of using GPIOs as shared memory,
though it does seems to be a common use case for those accustomed to accessing
hardware registers directly.

I would question whether "much more efficient" is true, as going through all
the gpiolib machinery, including the device driver, to perform the get could
even turn out to be slower than some IPC options - such as actual shared
memory.

Cheers,
Kent.