On Monday 11 May 2009, Narnakaje, Snehaprabha wrote: > Kevin, Dave, > > We checked this with the hardware team - > > "The GPIO module does't seem to have the ability to > enable/disable the direct/banked GPIO[0:9] at the GPIO > Level (it does via the SET register, but it doesn't > prevent triggering both Interrupts to the CPU). But the > option to mask between the direct GPIO interrupts and > the bank0 for GPIO[15:0] does exist at the ARM level.
That's not quite clear... if SET_FALLING.BIT(5) has enabled one edge and SET_RISING.BIT(1) enables another edge on a different GPIO, and BANK0 is enabled in the AINTC, then BANK0 can be triggered by either of those two events, right? (That's what we expect, and I've seen no reason to think otherwise. BINTEN.BIT(0) set.) If we then toss direct GPIO5 and GPIO1 IRQs into the mix, and they're both enabled in the AINTC ... you're saying both should arrive, yes? Triggered according to those RISING/FALLING settings? Or always active-low? If the RISING/FALLING registers are all clear, but the direct GPIO5 and GPIO1 IRQs are enabled in AINTC, are you saying we still get a BANK0 interrupt? > The direct mapped interrupt will trigger both Interrupts > to the CPU, in which case if both are required to be enabled > at the CPU level in a system, the user code inside the Banked > ISR should read the INTSTAT register to determine if it needs > to do anything (to address an interrupt that came from > GPIO[15:10] 6 pins ONLY) or simply ignore it because it > was one of GPIO[9:0] and in which case the direct ISR > will get serviced anyway." Right now the banked handler reads INTSTAT but doesn't try to check (for bank 0) whether one of the direct IRQ paths is active. It sounds like you're saying INTSTAT can have BIT(x) set even if FALLING(x) and RISING(x) are both clear... ? > Kevin's patch uses mask/unmask hooks. This patch seems to work fine for me as > well. Adding the mask() call when dispatching the bank IRQ seems like a clear bugfix. Switching enable/disable to unmask/mask should nearly be a NOP, other than preventing disable_irq() calls from doing anything. - Dave > > Thanks > Sneha > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf > > Of Kevin Hilman > > Sent: Monday, May 11, 2009 11:42 AM > > To: David Brownell > > Cc: [email protected] > > Subject: Re: GPIO interrupt problems > > > > 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 > > _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
