> 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. Regards, Richard W. - 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
