From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: David Brownell <david-b@pacbell.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] generic GPIO parameter API
Date: Fri, 6 Jun 2008 07:50:37 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.64.0806060744450.14536@axis700.grange> (raw)
In-Reply-To: <200806052229.37143.david-b@pacbell.net>
Hi David,
On Thu, 5 Jun 2008, David Brownell wrote:
> On Monday 02 June 2008, Guennadi Liakhovetski wrote:
> > Hi,
> >
> > as far as I understand, the current GPIO API only presents very basic GPIO
> > functionality: direction and level reading and writing. Whereas many GPIO
> > controllers have many further configurable parameters: pull-ups and
> > pull-downs, drive strength, slew rate, etc.
>
> Not at all how I'd describe it. Those omitted mechanisms are part
> of pin configuration, in the same way as function multiplexing is.
> (That is, assigning a given pin for use as a GPIO, vs hooking it up
> to an I2C, MMC, SPI, LCD, I2S, or memory controller.)
>
> Those mechanisms are highly chip-specific. Far more so than simple
> boolean GPIO mechanisms. With rare exceptions, they're needed only
> in platform-specific board setup code, which is already accessing
> lots of platform-specific programming interfaces. I'm really not
> keen on having them become part of the GPIO framework. The thought
> makes me think of trying to swallow a kitchen sink; sorry ...
Thanks for the lengthy explanation with numerous examples - this is
appreciated. But I'll omit that for this reply. Just a short question so
far - how would you handle an external GPIO expander with an additional
functionality, naimly, a possibility to switch pull-ups to GPIO pins,
specifically, it defines 4 modes for a pin: out high, out low, in without
a pullup and in with a pullup. And if the user application wants to decide
at run-time which pull-ups to switch and when? It's a MAX7301 from Maxim
btw.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
next prev parent reply other threads:[~2008-06-06 5:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 17:22 Guennadi Liakhovetski
2008-06-02 17:54 ` Guennadi Liakhovetski
2008-06-02 23:13 ` Ben Nizette
2008-06-03 6:42 ` Guennadi Liakhovetski
2008-06-03 7:32 ` Ben Nizette
2008-06-03 8:29 ` Guennadi Liakhovetski
2008-06-03 22:02 ` Ben Nizette
2008-06-06 5:29 ` David Brownell
2008-06-06 5:50 ` Guennadi Liakhovetski [this message]
2008-06-09 16:23 ` Guennadi Liakhovetski
2008-06-09 16:54 ` Mark Brown
2008-06-09 17:09 ` Guennadi Liakhovetski
2008-06-10 9:43 ` Mark Brown
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=Pine.LNX.4.64.0806060744450.14536@axis700.grange \
--to=g.liakhovetski@gmx.de \
--cc=david-b@pacbell.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®