Messages in this thread | | | From | David Brownell <> | Subject | Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation | Date | Tue, 21 Nov 2006 10:19:02 -0800 |
| |
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@billgatliff.com > - 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/
| |