mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ben Dooks <ben@fluff.org>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: Chris Boot <bootc@bootc.net>, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Proposal: common kernel-wide GPIO interface
Date: Sun, 30 Jul 2006 23:02:00 +0100	[thread overview]
Message-ID: <20060730220200.GB8907@home.fluff.org> (raw)
In-Reply-To: <20060730130811.GI10495@pengutronix.de>

On Sun, Jul 30, 2006 at 03:08:11PM +0200, Robert Schwebel wrote:
> Chris,
> 
> On Fri, Jul 28, 2006 at 09:44:40PM +0100, Chris Boot wrote:
> > I propose to develop a common way of registering and accessing GPIO pins on 
> > various devices.
> 
> I've attached the gpio framework we have developed a while ago; it is
> not ready for upstream, only tested on pxa and has probably several
> other drawbacks, but may be a start for your activities. One of the
> problems we've recently seen is that for example on PowerPCs you don't
> have such a clear "this is gpio pin x" nomenclature, so the question
> would be how to do the mapping here.

Right, my $0.02 worth:

1) The system does not currently allow for other GPIO sources
   than the CPU. There are a variety of GPIOs, that could come
   from expansion chips, on board CPLDs, etc.

2) The GPIO configuration from my last thought experiment have the
   following properties for each pin:

   input:
	- input
	- inverted input

   output:
	- normal output
	- inverted output
	- tristatable output
	- open collector (can only pull to zero)
	- open emmitor (can only pull to high)

   The allowance of inverted outputs, is very useful to allow
   drivers to assume either '0' or '1' is an active signal, allowing
   per-board fixups when the designer suddely decides the best way
   of connecting device A to B is via a spare inverter...

   The other way would be to allow the mapping of '0' and '1' states
   to either of the states:

	- output 1
	- output 0
	- tri-state

   The classing of tri-state as a seperate from input, is in case the
   hardware does not see input as a valid state, or that input and
   output are somehow different. 
  
   pull resistor:
	- tristate (no resistor)
	- pull low
	- pull high

   The input and output are seperate, assuming that there is the
   possiblity the system can read back the line even if the GPIO
   is set as an output.

3) The sysfs interface should be configurable, as systems
   with lots of GPIO would end up with large numbers of
   files and directories in sysfs.

4) you probably want to ensure pull-up resistors are off if the
   output is being driven. 

-- 
Ben (ben@fluff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'

  reply	other threads:[~2006-07-30 22:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-28 20:44 Chris Boot
2006-07-29 19:41 ` Bill Davidsen
2006-07-30 13:08 ` Robert Schwebel
2006-07-30 22:02   ` Ben Dooks [this message]
2006-07-31 16:10     ` Chris Boot
2006-07-31 20:17       ` Robert Schwebel
2006-07-31 21:23         ` Chris Boot
2006-08-01  7:40           ` Juergen Beisert
2006-08-01 15:53     ` Jim Cromie
2006-08-01 21:25   ` Jim Cromie
2006-08-02  7:28     ` Robert Schwebel
2006-08-02 17:58     ` Lennart Sorensen
2006-08-02 20:48       ` Jim Cromie
2006-08-03 13:55         ` Lennart Sorensen
2006-08-03 15:42           ` Robert Schwebel
2006-08-08 23:01         ` [RFC - patch] add a gpio-sysfs interface - was: " Jim Cromie
2006-08-09 17:12           ` Jim Cromie

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=20060730220200.GB8907@home.fluff.org \
    --to=ben@fluff.org \
    --cc=bootc@bootc.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=r.schwebel@pengutronix.de \
    /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®