Re: [PATCH] ARM: OMAP2+: Use handle_fasteoi_irq for INTC interrupt handling

[Tony Lindgren <tony@atomide.com>]

* Sørensen, Stefan <Stefan.Sorensen@spectralink.com> [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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html