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. /lauri - 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
