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

[David Brownell <david-b@pacbell.net>]

On Tuesday 21 November 2006 7:57 am, Bill Gatliff wrote:

> Once you're hiding the GPIO number behind an enumeration, you can create 
> a bitmap with more information than a single integer.  That extra 
> information could be used--- in my implementations, if any ever come 
> about--- to store routing information.

But none of the existing GPIO users do that.  The goal wasn't to define
a new notion of GPIO; it was collecting the existing ones under a single
arch-neutral umbrella.


> >It'd also be a big (and needless) disruption to code that's been working
> >fine for several years now ... 
> 
> ... all of which is using the current GPIO API, you mean?  :)

Effectively, yes.  I counted quite a few implementations in the current
tree which can trivially (#defines) map to that API.


> >Maybe if it were being done over from scratch, that'd be workable.
> >But at this point I have a hard time seeing anyone want to change,
> >even if there were a better argument.
> 
> Waitaminit.  I thought this arch-neutral GPIO API *was* a from-scratch!  
> Did I miss something?

The numerous implementations, e.g. on ARM, that effectively are
already using this same API, I'd guess.  The ones that uniformly
reference GPIOs by an integer.


> There's a ton of code in the AT91 tree that sets up pin routing on 
> behalf of peripheral drivers like MMC, etc.  MMC also uses GPIO. 

I just checked RC6, and see that at91_mmc doesn't set up routing.
Which is as it should be ... routing is part of board setup, saying
"these pins go to the MMC card".  Pretty much the same with all
other peripherals.  They do have calls to read GPIO values, or in
some cases set them.  But ** NOT ** to route them.


> Arabella's PPC Linux kernels (which I'm working with at the moment) have 
> a resource manager not unlike what we're discussing here.

Well, like _you_ are discussing.  I'm mostly pointing out that
pin muxing and configuration is a clearly distinct problem,
with very chip-specific nuances.


> It's very,  
> very heavy and unpleasant in spots, so I won't offer code or examples, 
> but it is pretty adept at getting pin routing right when a driver 
> initializes.  And it can also prevent pin assignment conflicts--- which 
> have saved me in a few situations, and made debugging easier in others.  
> I don't like their implementation, but the functionality is much-needed.

Most highly integrated chips nowadays need such functionality.  If you're
keen on it, you could try to abstract a dozen pin mux/setup implementations
and propose an API ... in the same way I did for GPIOs.  :)


> None of what I'm suggesting affects the signatures of the functions 
> specified by your API at all.  I'm just hiding more information behind 
> the notion of "gpio number", in a way that lets the implementors also 
> incorporate routing (both detection and assignment) into them.

And as I've defined those numbers, that's certainly allowed.  But not
required.  I'm just pushing back on the notion that it be required,
since adding such heavy requirements would prevent quick API support
for GPIOs.

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