Hi, * Woodruff, Richard <r-woodruff2@xxxxxx> [080114 06:14]: > > Following patch changes interrupt processing for OMAP3 to check for > > spurious > > bits and automatically ack if they are present. This allows the "bad > irq" > > error > > message to be generated, but prevents system getting stuck in un-acked > > interrupt loop. > > > > It would be very nice if somebody from TI could elaborate what exactly > is > > going on with these "spurious" interrupts, which according to TRM are > > only generated when interrupt mask is modified within 10 cycles of > raising > > an interrupt. This seems to happen quite a bit, easily triggered by > using > > serial console on ES2.0 hw. > > We have had problems on and off with this on our internal images. ARMv7 > seems more sensitive than ARMv6 was (we saw it in both). Up until now a > few tactical changes in drivers or at the system level has removed them > from production images. I'll see if I can find a mail where I > highlighted some causes other than the one you cite. > > One of those which may be a good one to try and fix is the fact that > ARM-Linux is marking peripheral control regions with a memory type which > allows posting (shared-device). This posting effect is magnified by all > the different internal timing domains which the data must cross. As the > ARM is so fast compared to the others we might have to synchronize in > more drivers if that aspect is not switched to strongly ordered. There > are some old posts where Russell says it's a must for mpcore, but I > don't think that is universally true as it is applied today. Richard, can you also describe the purpose of the spurious interrupt? Is it just an error on accessing the registers too soon before interrupt priority sorting is done, or something like that? 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
