Re: [libgpiod] feature request: output state read and sustain

["Jiří Prchal" <jiri.prchal@aksignal.cz>]

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@aksignal.cz> 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.