Date: Fri, 28 Oct 2005 14:33:20 -0400 From: John Baldwin <jhb@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: Mark Linimon <linimon@lonesome.com>, src-committers@freebsd.org, cvs-all@freebsd.org, Peter Wemm <peter@wemm.org>, cvs-src@freebsd.org Subject: Re: 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 ... Message-ID: <200510281433.22369.jhb@freebsd.org> In-Reply-To: <20051028160218.GJ41520@cell.sick.ru> References: <200510251948.j9PJmmmj043891@repoman.freebsd.org> <200510281041.44147.jhb@freebsd.org> <20051028160218.GJ41520@cell.sick.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510281433.22369.jhb>