>-----Original Message----- >From: David Brownell [mailto:[EMAIL PROTECTED] > >On Friday 17 August 2007, Mike Frysinger wrote: >> On 8/17/07, David Brownell <[EMAIL PROTECTED]> wrote: >> > ... >> > Just for the record, this is an unusual way to use these calls. >> > >> > Other platforms completely decouple these issues from the >> > IRQ infrastructure ... doing the pinmux and gpio claiming >> > separately from the request_irq()/free_irq() paths, mostly >> > as part of board setup. Doing all of that "early": >> > >> > - keeps those error returns from causing hard-to-track-down >> > runtime bugs; >> > >> > - works always, even on platforms where a given IRQ may >> > appear on any of several pins/balls; >> > >> > - makes it easier to cross-check against board schematics, >> > by keeping most board-specific setup in one source file; >> > >> > - shrinks the kernel's runtime footprint; >> > >> > - allows the label to be more descriptive ... describeing >> > exactly *which* IRQ, so that using the labels for better >> > diagnostics actually gives better diagnostics. >> > >> > Again, not "wrong"; but probably sub-optimal. You might >> > want to move towards earlier binding now, while Linux is >> > still young on Blackfin and you don't have legacy code to >> > worry about. >> >> in the Blackfin port, if you want to use a pin as an IRQ rather than >> GPIO, you use the normal request_irq/free_irq API ... those functions >> will call back into the proper GPIO/PORTMUX code so that the pin is >> setup properly. this is done so that code isnt duplicated across >> files and so that we can easily detect if someone does something >> incorrect like try to take the same pin and use it as >> irq/gpio/whatever at the same time ... >> >> are you saying that other ports dont unify the backend code paths at all >? > >Some platforms try to "unify" the pin setup in the boot loader. >Most of them cope with bogus bootloaders by doing it in the board >setup code. > >I don't know of any who try to do it "late" as you summarized. > >See above why "late" unification is not necessarily as good as >"early" unification. > >And then there's the OMAP1 example, where for example you might >know that you want MPUIO-0 but that's insufficient to tell whether >you must mux ball F18 or R13 ... so it's impossible to do the kind >of "late" unification done here, and pinmux *MUST* be separate from >IRQ setup.
Dave, We are not talking about PIN routing. One physical PIN/BALL can only have one dedicated function the same time. It's more about telling about possible conflicts, on a development board level. What Mike wants to point out is that a external IRQ is first a GPIO and needs to be configured like an INPUT GPIO and then a specific bit needs to be set unmask it as IRQ. So why not use the GPIO infrastructure to setup this pin as GPIO? -Michael > >- Dave - 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/
