Subject: Re: Device driver, fast interrupt vector conflict
To: Tim Walls <tim.walls@pa.press.net>
From: Jason Wright <jason@thought.net>
List: port-sparc
Date: 06/05/2000 11:28:53
On Mon, Jun 05, 2000 at 12:37:14PM +0100, Tim Walls wrote:
> Out of interest, what is that 'hands out' the interrupt levels to the
> devices?  Is it all decided by the PROM before boot, or does the NetBSD
> kernel allocate them??  Sun device programming is a bit new to me ;-)
> 
My understanding is that a given sbus card has a fixed sbus level that it
generates.  So card A will always request level X, etc.  Sharing interrupts
on sbus is possible (unlike some other bus's), so this works.

The interrupt logic basically loops through all of the devices at a given
level when an interrupt comes in.  The first device to "claim" the interrupt
(by returning 1) stops the list traversal.  Any unserviced interrupts will
keep the level asserted, so if you have device A and B requesting level X,
if A claims the interrupt and B still needs service, B will keep the level
asserted, and the list will be traversed again.

I think the hang you're running into is something I had to fix in OpenBSD.
There's no good way to know whether the audioamd has interrupted (someone
correct be if I'm wrong about this).  The audio device claims ALL interrupts
on that level (and since it's attached first, the spif never gets serviced,
but the level stays asserted).

Been there =)  Ran into this problem while writing this driver.

--Jason Wright