David Brownell <[email protected]> writes: > 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).
So far, I've only seen the direct interrupts affect bank 0. I'm hoping there isn't a new chip coming that expands this bug^H^H^Hfeature. >> 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. ;) Me too. This was found only through experimentation. >> 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. I hope board designers are aware of this. I think a general rule for board designers would simply be to not hook up the non direct-mapped GPIOs in bank 0. That would give the most flexibility. >> 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. > Thanks for the suggestions. > Seems like the notion for now is to make at least dm355 use direct > mapped IRQs on bank 0? Well, if the banked interrupts can work, I think it's simpler to just use banked interrupts or everything. But I still don't understand understand why the banked interrupt is not working like the direct mapped interrupt for the dm9000. And since dm365 doesn't have banked interrupts, we need a good solution for direct-mapped interrupts anyways so we can at least use that for bank 0 on dm355. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
