[openib-general] Re: Disabling IRQ #201 message

[Michael S. Tsirkin]

Quoting r. Grant Grundler <iod00d at hp.com>:
> Subject: Re: [openib-general] Re: Disabling IRQ #201 message
> 
> On Wed, Feb 02, 2005 at 03:37:05PM +0200, Michael S. Tsirkin wrote:
> > Pls consider:
> > 
> > EQ0 drives interrupt (low)
> > IRQ handler clears interrupt (high)
> > EQ1 drives interrupt (low)
> > IRQ handler reads ECR
> > IRQ handler serves EQ0 and EQ1
> > IRQ handler responds with IRQ handled
> 
> I think a step is missing here.
> 
> > 
> > all EQs are now empty, but interrupt line is low (asserted).
> 
> If the IRQ line is asserted and we get another interrupt for
> something we've already handled, then it means the regular
> interrupt code really hasn't cleaned up sufficiently.
> There has to be some way to tell the card what work has
> been done *OR* flush all inflight DMA (MMIO read - Ouch!).
> The interrupt handler needs to guarantee it has handled
> pending work and communicatied that back to the card so
> IRQ line is not asserted.

Well, the handler did this, but while it was doing other things
another interrupt got asserted.


> > I propose returning IRQ_HANDLED *always* in regular interrupt.
> 
> This totally breaks Shared IRQ support.

Why does it "totally break" it? We did suppress the interrupt
(write to clear interrupt register) so we return "HANDLED".
Its unavoidable that hardware may re-assert it while
the handler is still running.

> If the driver asserts it must have a private IRQ line
> in it's request_irq() call, then I would be ok with this.
> 
> grant
> 

-- 
MST - Michael S. Tsirkin