Message-Id: <200611111904.36817.david-b@pacbell.net>
Date:	Sat, 11 Nov 2006 19:04:34 -0800
From:	David Brownell <david-b@...bell.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Bill Gatliff <bgat@...lgatliff.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Saturday 11 November 2006 5:27 pm, H. Peter Anvin wrote:
> 
> If this is done, I think it's essential that a "high-level" API (one 
> that supports message-based GPIO) is provided at the same time. 

It's not a "high level" vs "low level" issue, though.  There are
dozens to hundreds of drivers that know they're using "real GPIOs",
and which *need* to do that.  For example, because the signals must
be accessed while holding a spinlock, or in_irq().

I'd like to see some "message based GPIO" API soonish, but can't buy
the notion that lack of one should be a blocking issue.  In fact,
if you go reread that LKML thread I referenced originally, you'll
notice that a key "why this can't fly" issue was that it didn't have
support for irq/spinlock safe GPIOs ... which make up by far the
majority of current GPIO users in Linux.


Lack of arch-neutral "real GPIO" calls is more or less a blocking
issue, given the merge of the AVR32 architecture ... unless you'd
like to argue it's a good thing to make drivers for integrated
controllers be (otherwise needlessly) be arch-specific?  One current
example is the "atmel_spi" driver, sharable between AVR32 and AT91;
Atmel reused a lot of the controllers from its AT91 ARM series when
they designed the AVR32 SOCs, and it doesn't make sense to have both
AT91 and AVR32 versions of the same drivers.


>		 The  
> "high-level" API should be able to address the GPIOs addressed by the 
> low-level API.  What we do *not* want is a bunch of stuff using the 
> low-level API when the high-level API would work.

If there were many (any?) drivers that didn't need to care, I might be
tempted to agree.  But there aren't ...

Another way to look at it is to notice how many spinlock-safe GPIO
APIs are in use **right now** on ARM ... that's on the order of a
dozen, which is a kind of existence proof that switching to the API in
the patch I sent would be a useful cleanup.   (And switching would be
mostly just syntax tweaks ... the primitives are all the same, except
for error checking; their names are just spelled differently.)

Even if there were only four platform specific drivers per architecture
which use GPIOs, that'd still be around 50 drivers that could stop using
arch-specific calls.  But some have many more than four, and I know there
are some drivers that never leave arch trees because they have no way to
get rid of platform-specific GPIO usage ...


And on the other side ... how many "message" based ones are there?
Darn few.  The pcf8574 driver is unusable by other kernel code, so
every board with a few of those chips has to roll its own solution;
inelegant, but not a burning issue.  And the tps65010 driver has a
solution that works OK now too.   A max7301 (spi) driver will need
to get a solutition for this too.

I suspect that userspace GPIO accessors should only be written once
though, and they're going to be in the "don't care" category.  So
lack of such a "message compatible" GPIO call set might reasonably
hold up merging that sort of (configfs?) interface.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists