"Griffis, Brad" <bgrif...@ti.com> 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 Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
