Re: [PATCH 02/12] Blackfin arch: Add label to call new GPIO API

["Mike Frysinger" <vapier.adi@gmail.com>]

On 8/17/07, David Brownell <david-b@pacbell.net> wrote:
> On Friday 17 August 2007, Mike Frysinger wrote:
> > On 8/17/07, David Brownell <david-b@pacbell.net> 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.

sorry, i'm not familiar at all with anything OMAP, but the Blackfin
architecture is such that all of its pins can be flipped on the fly
between modes ... i have seen once or twice some drivers which
actually needed this ability at runtime as they were muxing things
(maybe our fault there ... give someone the ability and they'll use
it).

as Michael pointed out, in the Blackfin world we tend to keep things
very dynamic as we have dev systems which allow for dropping in of
optional cards at will, so doing this in the bootloader is way too
inflexible.
-mike
-
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/