[lkml]   [2007]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH 02/12] Blackfin arch: Add label to call new GPIO API

>-----Original Message-----
>From: David Brownell []
>On Friday 17 August 2007, Mike Frysinger wrote:
>> On 8/17/07, David Brownell <> 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
>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.


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?


>- Dave
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-08-17 22:29    [from the cache]
©2003-2011 Jasper Spaans