* Felipe Contreras <felipe.contreras@xxxxxxxxx> [081021 14:34]: > On Tue, Oct 21, 2008 at 11:37 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Felipe Contreras <felipe.contreras@xxxxxxxxx> [081021 13:09]: > >> On Tue, Oct 21, 2008 at 7:58 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > >> > Hi all, > >> > > >> > Here's a bug fix for the irq -33 issue. So far it looks like the irq > >> > spurious bits just tell that the irq sorting is invalid. > >> > > >> > This patch applies after undoing Lauri's patch > >> > 5dc857b34441d5c0989b68bf3a488f89983b2645. > >> > >> You mean? > >> 3da0e10243d075b905dfa8f1b4a6cb3694ab2ce0 > > > > Oops yeah. > > > >> > Looks like there are still occasional spurious GPT12 interrupts, so > >> > I'm now looking into that. > >> > >> Works perfectly fine with my DSP tests :) > > > > Thanks for testing, good to hear. > > Hm, I forgot to revert acb7f8, so the test is not valid. I will try > again tomorrow. Well so far the only difference in my tests have been that with strongly ordered patch there are no spurious irq 95 interrupts, while without the strongly ordered patch there are occasional spurious irq 95 interrupts. These irq 95 interrupts without the strongly ordered patch are strange as I don't have GPT12 enabled. Also, when they occur, the INTCPS_SIR_IRQ bits for SPURIOUSIRQFLAG are set to 0x3ffffff instead of the normal 0 or 1. Anybody have an idea whtat the SPURIOUSIRQFLAG bits are supposed to tell in addition to the priority sorting information being valid or not? The spurious interrupts show up easily with Natan's DSP ping test. There's about one spurious irq 95 every two seconds or so. The system still keeps working normally. Anyways, I'll revert the earlier patch from Lauri, and apply this one. Will also add it to omap-fixes queue for the mainline kernel. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
