From: David Brownell <david-b@pacbell.net>
To: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Ben Nizette <bn@niasdigital.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
kernel@avr32linux.org
Subject: Re: Latest gpio gumph
Date: Wed, 28 May 2008 02:01:24 -0700 [thread overview]
Message-ID: <200805280201.24256.david-b@pacbell.net> (raw)
In-Reply-To: <20080528101425.611e0145@hskinnemo-gx745.norway.atmel.com>
On Wednesday 28 May 2008, Haavard Skinnemoen wrote:
> >
> > * gpio_direction_output() should disable the pullups just like
> > at32_select_gpio(... AT32_GPIOF_OUTPUT) does, for consistency
> > between those alternative initialization paths.
>
> But then we need to keep track of whether pullups used to be enabled so
> that we can re-enable it in gpio_direction_input(), don't we?
"Need"? I'd figure that changing direction like that would be
uncommon without something determining signal level (like an
external driver or pullup) ... and if nothing did so, then it'd
be important to use the AVR32-private API with pullup control.
> I can't see the harm of keeping the pullup enabled while the port is
> configured as output. For consistency, I'd rather honor the pullup flag
> in at32_select_gpio() regardless of AT32_GPIOF_OUTPUT.
I guess I don't like the idea of facilitating the constant current
waste that implies if output is being driven low. Even if it's not
a huge current waste! (These pullups being a lot weaker than I'd
have expected, at typically 190 kOhm.) No big deal here I guess.
For an open drain output it's probably less of an issue, unless
there are too many pullups.
> > * On the odd chance some code uses a pin as a GPIO IRQ without
> > calling gpio_request() or gpio_direction_input(), the debug
> > dump should still show its pin status.
>
> Hmm. I guess that makes sense, though I would be lying if I said I care
> all that much. I think gpiolib is going pretty far to accommodate buggy
> drivers that don't call gpio_request() as it is.
For diagnostic/debug code, I'd say it's reasonably useful to cope
with buglets like that.
I actually observed that happening. Setup code was passing the irq
to the driver, and everything worked fine because the reset default
was fine. I happened to notice that /sys/kernel/debug/gpio output
didn't match up to /proc/interrupts (bug) ... but it would have been
much faster to see the bug if the listing for that pin had a "?" label
showing that it hadn't been requested.
- Dave
next prev parent reply other threads:[~2008-05-28 9:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-28 2:41 Latest gpio gumph Ben Nizette
2008-05-28 4:44 ` David Brownell
2008-05-28 5:13 ` Ben Nizette
2008-05-28 8:14 ` Haavard Skinnemoen
2008-05-28 9:01 ` David Brownell [this message]
2008-05-28 9:21 ` Haavard Skinnemoen
2008-05-30 3:18 ` David Brownell
2008-06-10 11:58 ` Haavard Skinnemoen
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=200805280201.24256.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=bn@niasdigital.com \
--cc=haavard.skinnemoen@atmel.com \
--cc=kernel@avr32linux.org \
--cc=linux-kernel@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.