Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

[Paul Mundt <lethal@linux-sh.org>]

On Mon, Nov 20, 2006 at 09:35:38PM -0800, David Brownell wrote:
> On Monday 20 November 2006 9:09 pm, Bill Gatliff wrote:
> > 	It seems like the point 
> > here is to help a driver find and assert their GPIO _pin_ so that the 
> > driver can can talk to the attached external hardware.
> 
> Updating the GPIO controller is always (all architectures!) done in terms
> of a number mapping to some controller and a bit number, not a pin.  The
> drivers never care about pins.
> 
> The only thing that cares about pins is board setup code -- briefly.
> 
That's rather simplifying things. The driver using the GPIO number isn't
going to care about the pin number that it's associated with, but that's
not to say that another driver won't have an interest in the alternate
function of the pin that the GPIO is tied to, while the first driver is
expecting it to be used as a GPIO.

There is a need to layer a pin mux API underneath the GPIO API to deal
with these sorts of things, but that's obviously up to the platform to
take care of, and I think your API is a fairly good staging ground for
building up the layering in the platform parts.

Claiming that we set the pins once in the board setup code and then
forget about it is not realistic. I can't imagine anyone with many
different pin functions under mux (OMAP2 does too) seriously taking that
position.

So given that, I would argue that drivers _do_ care about the pins, just
not through the GPIO API.