"Narnakaje, Snehaprabha" <[email protected]> writes: > 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. > > 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."
Hmm, would've been nice to see something like this discussed in the GPIO docs. :) Something else that lacking from the docs is any sort of discussion around the advantages and/or disadvantage to using direct-mapped interrupts over banked interrupts. In any case, this is what I discovered through experimentation. But it is still quite cumbersome and would be a performance hit to take these extra interrupts just to figure out you have nothing to do. That's what I was trying to avoid. > Kevin's patch uses mask/unmask hooks. This patch seems to work fine > for me as well. Thanks for testing. Kevin >> -----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
