Thanks for bringing this to our attention. I've written the following wiki article about the issue:
http://wiki.davincidsp.com/index.php?title=Avoiding_Double_Interrupts_with_the_GPIO_Peripheral I'm going to send that link to the owner's of the GPIO user's guides in hopes of getting some kind of warning put into the guide. If nothing else though, at least it is now documented somewhere! Brad -----Original Message----- From: Kevin Hilman [mailto:[email protected]] Sent: Wednesday, May 13, 2009 4:17 PM To: Griffis, Brad Cc: David Brownell; Narnakaje, Snehaprabha; [email protected]; Alanis, Miguel Angel Subject: Re: GPIO interrupt problems "Griffis, Brad" <[email protected]> writes: > 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? > > You need to setup either a rising or falling edge interrupt in order > for an interrupt to be generated. If you don't set either one then > you will not generate any interrupts (bank or individual). > > I think the ultimate issue here is that the output of the interrupt > generation is tied directly to both the bank interrupt and the > individual interrupt. That means that the gating of this interrupt is > happening at the AINTC level. Therefore if you have both the > individual interrupt and the bank interrupt enabled at the AINTC level > then you will be interrupted twice for that specific interrupt. Yes, this is the root of the problem. And even more to the point, I discovered this via experimentation because it is far from clear in the docs how this works. > So, for example, if at the AINTC level you enable the individual > interrupt, but disable the bank interrupt, then you would be fine > (i.e. only one interrupt generated). However, if some other code in > the system turns on the bank interrupt then you will get interrupted > twice for a given interrupt (once for the individual and once for the > bank). > > You could solve this issue a few different ways. (I have not so much > as opened the driver so sorry that I have no idea how easy/difficult > these approaches will be to implement.) > > 1. Use only individual interrupts for GPIO[9:0] and don't let anyone > in the system use GPIO[15:10]. > > 2. Use only bank interrupts for GPIO[15:0] and don't let anyone use > the individual interrupts (GPIO[9:0]). This is the current approach. > 3. Use a mix of bank interrupts and individual interrupts, but > whenever an individual interrupt gets used you "plug" the > corresponding bank interrupt with a NOP. > > The first 2 solutions work by doing the gating at the AINTC level and > only allowing one of the interrupts to be enabled, thereby making it > impossible to be interrupted twice. Those solutions will be the most > efficient from a cycle perspective. The 3rd solution is the most > flexible because it allows both interrupts to be enabled but will have > wasted overhead from taking unnecessary interrupts. As the kernel moves towards threaded interrupts, there s an increased penalty in taking the redundant interrupt as well, so I'd like to avoid that wherever possible. Kevin _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
