Hi, > * Hiremath, Vaibhav <[email protected]> [090106 13:13]: > > For capture driver I am also getting similar messages > > > > <4>Spurious irq 95: 0xffffffdf, please flush posted write for irq 24 > > Spurious irq 95: 0xffffffdf, please flush posted write for irq 24 > > <4>Spurious irq 95: 0xffffffdf, please flush posted write for irq 24 > > Spurious irq 95: 0xffffffdf, please flush posted write for irq 24 > > The same solution should work in the irq 24 handler as well. Just do > a read-back of the last written register in the irq 24 handler. > > Or a read back of some safe register in the same device in case > you cannot read back the interrupt status register without clearing > the device interrupts :)
I'll re-raise the opinion that SO should be used for device mappings on OMAP. This is not just an IRQ issue. It's a generic one to programming a device and knowing when what you have written has taken. It just happens to be the IRQ path has a very slow dissertation path when you take into account timing domains that it shows up. Shrinking the race window with SO then using a read back to get the last one or two is most conservative and safe. Probably 97% for IO accesses are ok on OMAP as device, but that is probably 99.9% with SO. In our testing we may be able to make that 97 a 99. Still I'd rather not risk the 1% for production. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
