Message-Id: <200611211019.04603.david-b@pacbell.net>
Date:	Tue, 21 Nov 2006 10:19:02 -0800
From:	David Brownell <david-b@...bell.net>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.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: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation

On Monday 20 November 2006 9:51 pm, Bill Gatliff wrote:

> In OMAP, as far as I can tell after skimming the datasheet (and being 
> reminded why I avoid TI's microcontrollers!),

Microcontroller??  Hah!  That'd be MSP430, or AVR8, or an ARM7 ... when
it can run vmlinux, it seems far away from being a microcontroller!
Despite how long it can run on a teeny weeny battery.

You'd like OMAP2 better though, in terms of pin setup it's way nicer.
Each GPIO seems to correspond to a single pin.  Nobody much liked the
consequences of how OMAP1 did it.


> someone has to set up the  
> MUX so that a given GPIO can get to a specified pin.  And practically 
> speaking, what's soldered to a pin is nearly immutable for a given board 
> (or at least a particular revision; you won't change it in software 
> anyway!).

Yep; though there _is_ the model of "SOC-on-a-card" plugging into a
custom chassis (maybe an industrial app), as opposed to using custom
boards for everything.  Though if you think of the "board" as being
that whole chassis-plus-CPUcard assembly, it's still more or less
immutable as you described.


>      So for sanity's sake the GPIO "resource manager" would have  
> to refuse a request for a GPIO line assigned to a pin that had already 
> been committed to something else, be it another GPIO line or a 
> peripheral function.  So I think having the notion of a resource manager 
> _at all_ implies that you're into some amount of MUX analysis/management 
> on machines that have them.

That's a big "if".  There's no such "manager" right now, other than the
people designing a given board and putting Linux onto it.


> Aside: You state that there are many-to-many possibilities.  In theory 
> yes, but for OMAP and any other practical machine, no.  You never have 
> an infinite number of pins or GPIOs, so even with some kind of radical 
> "switch fabric" the number of unique combinations of GPIO+pin still 
> would be bounded.  In the case of OMAP, it looks like most of the GPIOs 
> can be assigned to one of two pins, and each pin can be assigned to one 
> of two GPIOs.  So, "some-to-some".  :)

My point was more that it's "not one-to-one".  And clearly a given system
will only use one mapping (Paul's comments aside) ... the issue is that
knowing you're using a particular GPIO doesn't mean you know what pin is
involved, and contrariwise that knowing what pin doesn't mean you know what
GPIO to use.

Yes it's a PITA ... and I've seen boards that needed to get re-spun because
the board desigersn goofed, with two different interfaces expecting to mux a
(different) pin to GPIO7.  Didn't get discovered till late since each of the
two interfaces worked fine by themselves; system integration testing found it.
I suspect that's one reason OMAP2 is different in how it does the pin setup!


> The "multiplexing" that I was wishing to leave out of the GPIO API was 
> the part where you assign pins to peripheral functions *or* GPIO, a'la 
> AT91.  The existing kernel code for that chip provides a number of 
> functions to help board authors get all the routing and configuration 
> right for each pin ("peripheral A function, or peripheral B, or GPIO?  
> Input, or output?  Pullup resistor, or no?  Input filtering, or no?") 
> (*).  I'm ok with not trying to consolidate that functionality in an 
> arch-neutral GPIO-only API right now, since machines do that so differently.

Yes, I think we're seeing agreement on that now.


> But I was assuming all along that we were overloading the notion of a 
> "gpio number" enumeration, such that each enumeration ultimately 
> referred to a unique combination of GPIO+pin for the instant machine.  

Well, none of the existing software does that, or has needed to.

To the extent that the $SUBJECT calls are just common syntax for
what many platforms are already doing, they all use the same notion
of a "gpio number" which doesn't reference pinout ... there's a
direct mapping to a bit in a gpio controller register, that's it.


> And once you've got that, there's no reason why the underlying 
> implementation couldn't assert the proper routing at the time a specific 
> GPIO+pin was requested.  Maybe that's up to the individual authors as to 
> whether they want to provide this in their implementations, or choose 
> instead to leave out the MUX configuration and just map GPIO 
> enumerations to physical GPIO line numbers (and hope for the best at 
> runtime).  But I still don't see a reason why they shouldn't if they're 
> willing to do the code.

They could; the GPIO numbers, and interpretation, are platform-specific.

 
> Sorry to recycle on all of this again.  Maybe I'm just a slow learner, 
> maybe I just was misunderstanding some of the terminology we were 
> throwing around.  Maybe it's something else entirely.

Who knows.  I thought you were most likely wishing everything was as
simple and straightforward as it is on AT91, AVR32, and OMAP2.  ;)

In the restricted context of GPIO numbers, I think it is.  And it might
even be practical to come up with a widely used pin mux API ... it's
just that significant platforms like OMAP1 would be unlikely to fit.

- Dave



> 
> 
> * - Most of which was written by Dave Brownell.  Thanks!
> 
> 
> 
> b.g.
> 
> -- 
> Bill Gatliff
> bgat@...lgatliff.com
> 
-
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