cvs commit: src/sys/alpha/alpha interrupt.c src/sys/alpha/isa isa.c src/sys/amd64/amd64 intr_machdep.c src/sys/amd64/include intr_machdep.h src/sys/amd64/isa atpic.c src/sys/arm/arm intr.c src/sys/dev/sio sio.c src/sys/dev/uart uart_kbd_sun.c uart_tty.c ...

[John Baldwin]

On Friday 28 October 2005 12:02 pm, Gleb Smirnoff wrote:
>   John,
>
> On Fri, Oct 28, 2005 at 10:41:42AM -0400, John Baldwin wrote:
> J> > Of course the real challenge is to make things like the puc device do
> J> > the right thing automatically instead of needing 'options
> J> > PUC_FASTINTR'.
> J>
> J> You mean like sio(4) tried to?  The problem is that with the previosu
> code if J> sio(4) went first, it would register INTR_FAST and some later
> PCI device J> wouldn't be able to register its interrupt.  There's not an
> easy solution to J> that problem if you want to keep the semantics that
> INTR_FAST implies J> INTR_EXCL.
>
> is it possible to implement such a feature that driver requests INTR_FAST
> and it succeds only and only if interrupt isn't shared?
>
> For example I've got a console server with three puc devices. Since one of
> them share its irq with ATA, I can't trun on PUC_FASTINTR on this box.
> However, theoretically it is possible two make two pucs use a fast
> interrupt handler and one not.

INTR_EXCL will do this for bus_setup_intr().  INTR_FAST used to basically 
imply INTR_EXCL.  However, the definition of 'shared' is poor, and that's the 
hard problem.  The current definition of shared is 'does anyone else have a 
handler registered already'.   However, that definition isn't very adequate.  
In your example, if the puc that shares its IRQ with ATA probes first, then 
it's INTR_EXCL request will succeed, but ATA won't be able to setup an 
interrupt handler.  If ATA probes first, then puc will fall back to 
non-INTR_FAST (which is what sio(4) does except sio(4) depends on INTR_FAST 
implying INTR_EXCL which it no longer does).  One possible idea is to walk 
the entire PCI device tree first to "reserve" interrupts somehow, but that 
doesn't take into account drivers that don't actually use interrupts, or 
drivers that use MSI interrupts and not intpin interrupts (coming in the not 
too distant future), etc.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org