From: Gilles BULOZ <gilles.buloz@kontron.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [questions] : gpiolib and gpioset behaviour
Date: Mon, 22 Apr 2024 18:49:05 +0200 [thread overview]
Message-ID: <04e6ac4e-0178-c910-2dcd-45a726f75c0d@kontron.com> (raw)
In-Reply-To: <CAMRc=MdQ8CT7uxBRhPmttNhm5kzp1+Vij2LmVGO0QsA0xUPtNQ@mail.gmail.com>
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@kontron.com> 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.
>
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.
> Bart
>
> [1] https://lore.kernel.org/linux-gpio/20240412122804.109323-1-brgl@bgdev.pl/
> .
next prev parent reply other threads:[~2024-04-22 16:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 12:44 [questions] : gpiolib and gpioset behaviour Gilles BULOZ
2024-04-22 15:55 ` Bartosz Golaszewski
2024-04-22 16:49 ` Gilles BULOZ [this message]
2024-04-22 18:04 ` Bartosz Golaszewski
2024-04-26 2:07 ` Kent Gibson
2024-04-26 13:08 ` Gilles BULOZ
2024-04-26 13:37 ` Kent Gibson
2024-04-26 16:16 ` Gilles BULOZ
2024-04-27 0:23 ` Kent Gibson
2024-04-27 12:09 ` Kent Gibson
2024-04-29 8:50 ` Gilles BULOZ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04e6ac4e-0178-c910-2dcd-45a726f75c0d@kontron.com \
--to=gilles.buloz@kontron.com \
--cc=brgl@bgdev.pl \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.