On Friday 08 May 2009, Kevin Hilman wrote:
> After a bit more debugging on the GPIO interrupt issues, I think there
> is a fundamental hardware limitation in having flexibility of using
> GPIO bank interrupts and direct interrupts at the same time.
And to clarify: a "bank" is 16 interrupts, and the only
set of GPIOs where the confusion arises is the first one
(bank 0) where the first several GPIOs can get IRQs routed
either directly (handler gets installed to AINTC) or else
indirectly (chained through a bank handler).
> In order to configure a GPIO as an interrupt (either banked or
> direct), you have to set the edge-detection mode via the
> [SET|CLR]_RIS_TRIG, [SET|CLR]_FAL_TRIG registers. Setting these also
> has the side effect of enabling/disabling the interrupt.
>
> The catch is that this enables the *both* the direct interrupt and the
> banked interrupt and there appears to be no way to enable them
> independently.
This behavior was not specified in any technical docs I've seen.
I had suspected there was something interesting going on there...
such "hole in the documentation" cases make me suspicious. ;)
> The only way to prevent both interrupts from firing (and causing two
> handlers to run) is to mask one of them at the AINTC. Of course,
> masking the banked interrupt at the AINTC means you mask all GPIOs in
> that bank. So, within a given bank, it's not practical to use a
> mixture of direct and banked interrupts as they could not be
> individually masked on a per-GPIO basis.
Yuck!
> On dm646x, dm355 and dm646x, this is really only problematic for GPIO
> bank 0 where there are GPIOs that can be configured both ways.
> Essentially, the non-direct mapped GPIOs in bank 0 become pretty
> useless.
Well, one or the other becomes useless...
And when using the direct mapped IRQs, only a subset of that bank's
GPIOs will have IRQs at all:
- dm355, gpios 0..9 have direct IRQs, 10..15 don't.
- dm6446 and dm6467, gpios 0..7 have them, 8..15 don't
- ... etc
If there *are* banked IRQs, they'll be available for
everything except that first bank.
> On dm365, there appear to be only direct interrupts, and on omap-l1x,
> a quick glance at the interrupt table suggests that there are only
> banked interrupts. Both of those will be simpler to handle then when
> both are present.
>
> I guess I need to think about how better to extend the current GPIO
> code to be able to handle both cleanly.
The GPIO part is easy; the IRQ config/handling is a bit trickier:
First, note that <mach/gpio.h> is what defines gpio_to_irq() ...
and it *could* be using __gpio_to_irq(), but doesn't. Change it:
#define gpio_to_irq __gpio_to_irq
Then provide definitions for gpio.c::chips[*].chip.to_irq():
- If using a banked IRQ, use a method that looks
exactly like today's gpio_to_irq().
- If using a direct mapped one, use one that
makes sure the GPIO *has* a direct IRQ, and
either returns that or else returns -EINVAL.
And don't set up chaining for that bank
So the dm365 will use the second scheme (new), omap-l1x
will use the current scheme, other chips use the current
scheme everywhere ... except optionally for bank 0. Those
two steps cover the pure GPIO bits.
Third, some variant of the AINTC irq_chip for non-banked cases
will be needed. Presumably a new name; certainly set_type()
should control triggering. Maybe it'd be as simple as cloning
the AINTC chip then stuffing it with the enable/disable/set_type
methods from the GPIO chip. Maybe not.
Seems like the notion for now is to make at least dm355
use direct mapped IRQs on bank 0?
- Dave
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
