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
> [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]
