"Griffis, Brad" <[email protected]> writes: > FYI, I just added one other topic and an updated block diagram as well: > > http://tiexpressdsp.com/index.php?title=Configuring_GPIO_Interrupts
Brad, Thanks for all your wiki updates for GPIO. This is a huge improvement. Hopefully you have some luck getting better descriptions into the technical docs too. > Kevin, I saw some mention of level-sensitive interrupts in one of > your patches for GPIO. Could you elaborate on what you're talking > about there? To my knowledge we don't have any level-sensitive > interrupts. I was talking about the bank interrupt at the AINTC, not any GPIO interrupts. All the AINTC interrupts (except the timer) are currently handled as a level interrupts. IOW, they it masked during the handling. Kevin > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Griffis, Brad > Sent: Thursday, May 14, 2009 11:48 AM > To: Kevin Hilman > Cc: [email protected]; Alanis, Miguel Angel > Subject: RE: GPIO interrupt problems > > 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
