On Fri, Oct 31, 2008 at 9:21 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Hi all, > > So it's now starting to look like we need to ensure write posting in > interrupt handlers for 34xx instead of marking the IO areas as strongly > ordered. > > The first patch in the series reverts marking the IO areas as strongly > ordered. > > The second debug patch also prints out the previous interrupt before > the spurious interrupt, which should help identify the interrupt > handler that needs a read back of some register. > > So if you see errors like this with dspbridge: > > FIXME: spurious irq 95: 0xffffffdf previous irq 26 > FIXME: spurious irq 95: 0xffffffdf previous irq 26 > FIXME: spurious irq 95: 0xffffffdf previous irq 26 > ... > > You'll know that the interrupt handler for irq 26 needs a read back > of some register in the interrupt handler. Most likely you need to > read back the interrupt ack register right after writing to it in > the handler, see a later patch in this series for dspbridge. > > If you get errors like this during boot: > > FIXME: spurious irq 95: 0xffffffdf previous irq 25 > FIXME: spurious irq 95: 0xffffffdf previous irq 25 > FIXME: spurious irq 95: 0xffffffdf previous irq 37 > ... > > Most likely we need to do a read back when initializing some devices > like dispc and gptimer. I don't have patches for these yet.. > > The other patches fix few interrupt handlers that I'm aware of needing > this, like i2c-omap and dspbridge. The dspbridge patch only applies > if you have it installed. > > I'd appreciate if people who have been working on this issue would > torture test this series and provide feedback! I tried with various dsp tests, and as you mentioned, I was able to see lots of spurious irq warnings, then I applied patch #4, and those went away. No issues. -- Felipe Contreras -- 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
