mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®