* Sørensen, Stefan <Stefan.Sorensen@xxxxxxxxxxxxxxx> [140306 06:36]: > On Mon, 2014-03-03 at 09:49 -0800, Tony Lindgren wrote: > > > 1. CPSW device asserts TX IRQ > > > 2. CPSW device asserts RX IRQ > > > 3. INTC interrupts CPU, TX IRQ marked as active > > > 4. omap_intc_handle_irq ACKs TX IRQ on the INTC > > > 5. INTC marks RX IRQ as active > > > 6. omap_intc_handle_irq calls cpsw_interrupt > > > 7. cpsw_interrupt disables RX+TX IRQ in CPSW device > > > 8. cpsw_interrupt disables RX+TX IRQ in INTC (the IRQs are masked) > > > 9.. omap_intc_handle_irq sees no unmasked IRQs are pending and returns > > > 10. INTC interrupts CPU, RX IRQ marked as pending > > > 11. omap_intc_handle_irq sees no unmasked IRQs are pending and returns > > > 12. Go to step 10 > > > > > > The problem arises in step 8 where an active IRQ is masked. This will > > > not make it inactive in the INTC but it will be cleared from the > > > pending IRQ registers - this is the register that omap_intc_handle_irq > > > uses to decide which IRQ is active. > > > > OK thanks for the info. Looking at your trace above it seems like the > > two separate TX and RX INTC interrupts are not really treated as separate > > interrupts in the cpsw driver. It seems the real fix is to fix up the > > cpsw interrupt handler so it's not racy. It seems that at least step 7 > > and 8 above should be handled separately for TX and RX based on the INTC > > interrupts. > > Looking in drivers/net/ethernet, it looks like a quite common pattern > is to handle both RXx and TX interrupts with the same handler, which > will disable both interrupts and then hand off to napi. The cpsw driver > works the same way, so shouldn't this work on omap? Hmm yes at least disable_irq should work no matter when it's called. > > From the INTC point of view we should just have standard level IRQ > > handling for each interrupt, right? INTC does not need to know about > > driver specific coordination between two separate interrupts. > > The problem is that the INTC is not doing 100% level IRQ handling > combined with the way we handle the INTC during interrupts. When a IRQ > has become active on the INTC it will stay active until we acknowledge > it, even if it is masked or de-asserted. Yes it's starting to sound that INTC has an issuerecovering from the spurious interrupts. > My patch does not fix the problem when the active interrupt was > de-asserted, so I am looking into other ways of dealing with it. OK. Regards, 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
