David Brownell wrote:
But in general, no ... the general case is that GPIO controller(s)
and pin muxing are two separate units in the silicon, and there's
no one-to-one coupling possible.
Not sure I believe that there's "no one-to-one coupling possible"
anymore. :)
In OMAP, as far as I can tell after skimming the datasheet (and being
reminded why I avoid TI's microcontrollers!), 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!). 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.
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". :)
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.
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.
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.
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.
* - Most of which was written by Dave Brownell. Thanks!
b.g.
--
Bill Gatliff
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
