[Top] [All Lists]

Re: [PATCH] MIPS: DECstation I/O ASIC DMA interrupt handling fix

To: Ralf Baechle <>
Subject: Re: [PATCH] MIPS: DECstation I/O ASIC DMA interrupt handling fix
From: "Maciej W. Rozycki" <>
Date: Sat, 14 Sep 2013 23:57:47 +0100 (BST)
In-reply-to: <>
List-archive: <>
List-help: <>
List-id: linux-mips <>
List-owner: <>
List-post: <>
List-software: Ecartis version 1.0.0
List-subscribe: <>
List-unsubscribe: <>
Original-recipient: rfc822;
References: <>
User-agent: Alpine 2.03 (LFD 1266 2009-07-14)
On Thu, 12 Sep 2013, Maciej W. Rozycki wrote:

> This change complements commit d0da7c002f7b2a93582187a9e3f73891a01d8ee4 
> and brings clear_ioasic_irq back, renaming it to clear_ioasic_dma_irq at 
> the same time, to make I/O ASIC DMA interrupts functional.
> Unlike ordinary I/O ASIC interrupts DMA interrupts need to be deasserted 
> by software by writing 0 to the respective bit in I/O ASIC's System 
> Interrupt Register (SIR), similarly to how CP0.Cause.IP0 and CP0.Cause.IP1 
> bits are handled in the CPU (the difference is SIR DMA interrupt bits are 
> R/W0C so there's no need for an RMW cycle).  Otherwise the handler is 
> reentered over and over again.
> The only current user is the DEC LANCE Ethernet driver and its extremely 
> uncommon DMA memory error handler that does not care when exactly the 
> interrupt is cleared.  Anticipating the use of DMA interrupts by the Zilog 
> SCC driver this change however exports clear_ioasic_dma_irq for device 
> drivers to choose the right application-specific sequence to clear the 
> request explicitly rather than calling it implicitly in the .irq_eoi 
> handler of `struct irq_chip'.  Previously these interrupts were cleared in 
> the .end handler of the said structure, before it was removed.
> Signed-off-by: Maciej W. Rozycki <>
> ---

 Please withdraw this change, I'll send a better one (to say nothing of 
the bug it has).  I think with a trick we can handle the two kinds of I/O 
ASIC DMA interrupts DECstations have (informational and errors) 
transparently, no need for an explicit action in the handler.


<Prev in Thread] Current Thread [Next in Thread>