From: Kent Gibson <warthog618@gmail.com>
To: "Jiří Prchal" <jiri.prchal@aksignal.cz>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Bartosz Golaszewski <brgl@bgdev.pl>
Subject: Re: [libgpiod] feature request: output state read and sustain
Date: Wed, 29 Jun 2022 19:25:19 +0800 [thread overview]
Message-ID: <20220629112519.GA30910@sol> (raw)
In-Reply-To: <b8d63150-cd1d-692a-9470-d75278135350@aksignal.cz>
On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote:
>
>
> 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.
>
No, no it is not RAM.
And I have seen hardware where you can't read back the output.
And so has Andy apparently.
That is the problem - there is lots of hardware out there and we are
trying to provide a consistent interface to inconsistent hardware.
Cheers,
Kent.
next prev parent reply other threads:[~2022-06-29 11:25 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 10:02 [libgpiod] bug: pull-up does not work Jiří Prchal
2022-03-25 14:57 ` Kent Gibson
2022-03-25 15:13 ` Jiří Prchal
2022-03-25 16:01 ` Kent Gibson
2022-03-28 7:12 ` Jiří Prchal
2022-03-28 8:08 ` Kent Gibson
2022-03-28 8:58 ` Jiří Prchal
2022-03-28 9:56 ` Kent Gibson
2022-06-28 13:08 ` [libgpiod] feature request: output state read and sustain Jiří Prchal
2022-06-29 7:23 ` Kent Gibson
2022-06-29 9:25 ` Jiří Prchal
2022-06-29 10:10 ` Kent Gibson
2022-06-29 10:27 ` Andy Shevchenko
2022-06-29 10:47 ` Kent Gibson
2022-06-29 10:58 ` Andy Shevchenko
2022-06-29 11:20 ` Kent Gibson
2022-06-29 11:55 ` Andy Shevchenko
2022-06-29 12:56 ` Bartosz Golaszewski
2022-06-29 15:22 ` Andy Shevchenko
2022-06-29 11:17 ` Jiří Prchal
2022-06-29 11:25 ` Kent Gibson [this message]
2022-06-29 11:48 ` Jiří Prchal
2022-06-29 12:51 ` Kent Gibson
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=20220629112519.GA30910@sol \
--to=warthog618@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=jiri.prchal@aksignal.cz \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).