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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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

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.

Stefan

��.n��������+%������w��{.n�����{�������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f





[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux