From: Kent Gibson <warthog618@gmail.com>
To: Hans Kurscheidt <lve0200@gmail.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>,
Bartosz Golaszewski <brgl@bgdev.pl>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>
Subject: Re: gpiod: Set pullup for Input Line
Date: Wed, 23 Mar 2022 00:12:04 +0800 [thread overview]
Message-ID: <20220322161204.GC131091@sol> (raw)
In-Reply-To: <2884d1a0-4e4e-142f-0d3d-02d5e5e46466@gmail.com>
On Tue, Mar 22, 2022 at 10:39:00AM +0100, Hans Kurscheidt wrote:
>
> Am 22.03.2022 um 09:50 schrieb Andy Shevchenko:
> > On Tue, Mar 22, 2022 at 10:39 AM Hans Kurscheidt <lve0200@gmail.com> wrote:
> > > Am 22.03.2022 um 09:36 schrieb Hans Kurscheidt:
> > > > Am 22.03.2022 um 01:59 schrieb Kent Gibson:
> > ...
> >
> > > > Still 1 more question. I understand the sense of a Pull-up in Input
> > > > mode, but reading the code, I see that the Bias option exists as well
> > > > for gpioset (Output). What is the sense of this, and what does it do?
> > I guess we started providing OPEN SOURCE / DRAIN in libgpiod v2.0
> > (Bart or Kent may correct me), but you should get an idea why it may
> > be useful.
> >
> > On top of that, the pin can be reconfigured from input to output and
> > vice versa at run-time. So, keeping a bias setting will allow not to
> > think about it when pin direction is switched, although I agree this
> > may not be a clean case to use.
>
> Hi Andy,
>
> Open Source/Drain is completely different from Pull_UP/DOWN! Open
> source/drain defines, which active element (transistor) is attached to the
> line, while pull_up/down defines, which passive element (resistor) is
> attached to the line. In some sense one could say, what pull_up/down is for
> input, open drain/source is the corresponding thing for output, but they are
> realized by different means. IMHO, "bias" (pull-up/down) should be an option
> for gpioget, while "drive" makes only sense for gpioset, because I
> understand them as mutually excluding, but may be, I'm overseeing something.
>
You understand that with open drain/source there is one state where the
line is not driven by the chip, but goes high impedance and is driven
by the external circuit?
And the bias can be considered to be part of the external circuit?
If so, not sure what your issue is here. You agree that drive and bias are
totally independent, but take issue at being able to set them
independently in gpioset? What am I missing?
And there IS a bias option for gpioget - as it makes sense there as
well. And gpiomon as well.
> Unfortunately, this leads me to yet another question: Bias defines "as-is"
> and "pull-up/down" as options. Just to be sure, that would imply that one
> has to set the bias option to pull_up/down for the first call to gpioget and
> that subsequent readings from the input pin should/can run w/out the bias
> option, hence "as-is", or do you recommend to have the bias option specified
> for each read from the pin?
>
The "as-is" is an unfortunate side-effect of bias being a late addition
to the API, though it could be argued that it is useful in its own
right, as Andy mentioned.
Its main purpose is for backwards compatibility and is the default for that
reason.
If you need a bias then set it as needed. I would use options consistently,
not have different options on subsequent calls.
I would also recommend using edge events, such as those provided by
gpiomon, rather than polling with gpioget, but that depends on the complexity
of your use case.
Cheers,
Kent.
next prev parent reply other threads:[~2022-03-22 16:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 10:43 gpiod: Set pullup for Input Line Hans Kurscheidt
2022-03-21 13:34 ` Alexander Dahl
2022-03-21 16:26 ` Andy Shevchenko
2022-03-21 17:27 ` Hans Kurscheidt
2022-03-21 17:33 ` Andy Shevchenko
2022-03-21 18:17 ` Hans Kurscheidt
2022-03-21 20:25 ` Fwd: " Hans Kurscheidt
2022-03-22 0:59 ` Kent Gibson
[not found] ` <1a7fd31a-221e-7b23-b95f-d71e440b3ff0@gmail.com>
2022-03-22 8:39 ` Hans Kurscheidt
2022-03-22 8:50 ` Andy Shevchenko
2022-03-22 9:39 ` Hans Kurscheidt
2022-03-22 16:12 ` Kent Gibson [this message]
2022-03-22 16:11 ` Kent Gibson
2022-03-22 16:11 ` Kent Gibson
[not found] <ab3240e5-df61-cff4-ebba-f6a7e5d99f52@gmail.com>
2022-03-21 13:48 ` Hans Kurscheidt
2022-03-21 14:42 ` Alexander Dahl
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=20220322161204.GC131091@sol \
--to=warthog618@gmail.com \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=linux-gpio@vger.kernel.org \
--cc=lve0200@gmail.com \
/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).