On 29. 06. 22 12:47, Kent Gibson wrote:
On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote:
On 29. 06. 22 9:23, Kent Gibson wrote:
On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:
using new libgpiod / chardev driver, is there any way to get state of
output? I mean one process sets it for example to 1 and another process
reads this output state for example to show that on web page.
I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
chips may not allow this on H/W level and when reading they always
will get the value of Input Buffer (now imagine if the line is
configured as Output with Input being disconnected from the physical
pin).
Agreed. Userspace should know the value they set the output to, and so
have no need to read it back. GPIO is not NVM.
Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.
The only time it makes sense to me to go to the hardware for output
values is for open-drain outputs, but as you say, even then it would
depend in the hardware and driver supporting it. And for those cases it
might be better to explicitly emulate open-drain and switch the line to
an input when not being actively drive.
Open-drain outputs as many HW as I know has separate register for output to switch on and off the tranzistor and input register to read value on pin.
So 2 values are needed from o-d outputs. OK, first could be write only and second read only.
I have to say that old sysfs interface was more user friendly...
And much more buggy and PITA.
"new" being anything since Linux 4.8 ;-)?
And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
provide an interface to the chip driver. More on that later.
Only the process holding the line has access to the current value.
If you need that value elsewhere then it has to be published by that
process - it is not available through the GPIO API itself.
There is nothing preventing that process publishing the value
in whatever way is appropriate to your application.
e.g. write it to a file that can be read by your webapp, just as it
would from sysfs.
Less restrictive access models are frequently "more user friendly", but
have other issues. e.g. some misbehaving process just reset your
modem for you.
And sysfs has other great features like being slow and being complete
rubbish for events on input lines.
And at second: it would be better to NOT "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."
"Set and forget" behavior is more natural to what some gpios are used. For
example resetting external modems, need set 1 for short time, then to 0 and
leave it for long long time until next reset is needed. It's non sense to
keep running some process only to keep output at 0.
Agreed, that might be more natural, but that behaviour is not by choice,
it is a consequence of the kernel internals. In short, if the GPIO
subsystem does not hold the chip then the driver is free to do what it
likes to it.
So when you release a line all bets are off.
It may stay where you left it, but it may not - it may even switch to an
input - it depends on the driver.
Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?
No, it's only about the line in question.
If it works for you that's great, but without major kernel changes
libgpiod has no better option than to provide the caveat as the "set and
forget" behaviour is something that it cannot guarantee.
Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
when the proces dies systemd will start it again
Do not use shell. Use proper programming language that may give you an
easier way of handling this, i.e. _context_. Shell tools are
_context-less_ and here is the problem you are trying to solve, but
from the wrong end.
Actually my proposed gpioset for v2 will support running interactively
so it can maintain context and be driven from shell - for cases where
basic scripting will suffice.
It would be nice.
Jiri
Cheers,
Kent.
