Date: Sat, 29 Oct 2005 13:20:07 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Warner Losh <imp@bsdimp.com> Cc: src-committers@freebsd.org, jhb@freebsd.org, peter@wemm.org, cvs-src@freebsd.org, cvs-all@freebsd.org, glebius@freebsd.org, linimon@lonesome.com 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: <20051029124828.C30731@delplex.bde.org> In-Reply-To: <20051028.103709.74689710.imp@bsdimp.com> References: <200510261648.27126.peter@wemm.org> <200510281041.44147.jhb@freebsd.org> <20051028160218.GJ41520@cell.sick.ru> <20051028.103709.74689710.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Oct 2005, Warner Losh wrote: > From: Gleb Smirnoff <glebius@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 ... > Date: Fri, 28 Oct 2005 20:02:18 +0400 > >> John, >> >> On Fri, Oct 28, 2005 at 10:41:42AM -0400, John Baldwin wrote: [peter 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. sio never tried to handle this. It just expresses its preference for INTR_FAST by trying for INTR_FAST first, and then expresses its capability of not using INTR_FAST by retrying without INTR_FAST. Higher layers have no support for allowing drivers to do the right thing, which is for the drivers to make just 1 call to bus_setup_intr(), with preferences and capabilities expressed in the flags, and higher layers wiring the interrupts dynamically so as to satisfy the most preferences while staying within capabilities. The PUC_FASTINTR hack handles this poorly. The CY_PCI_FASTINTR hack handles this poorly, but not as poorly as the PUC_FASTINTR hack since it has a smaller scope. The log message that added CY_PUC_FASTINTR points out part of the problem fixed in this commit: % RCS file: /home/ncvs/src/sys/dev/cy/cy_pci.c,v % Working file: cy_pci.c % ---------------------------- % revision 1.10 % date: 1999/01/15 10:00:12; author: bde; state: Exp; lines: +13 -2 % branches: 1.10.2; % Use a fast interrupt handler for the PCI version of the cy driver % if option CY_PCI_FASTINTR is configured and mapping the irq to a % fastintr is possible. Unfortunately, this has to be optional because % pci_map_int_right() doesn't handle the INTR_EXCL flag right -- % INTR_EXCL is honoured even if the interrupt needs to be non-exclusive % for other devices to work. % ---------------------------- >> is it possible to implement such a feature that driver requests INTR_FAST >> and it succeds only and only if interrupt isn't shared? This is exactly what we had. It doesn't work... > Not really. The problem is that you don't know it is shared until it > is too late. You have no way of really knowing if a device uses > interrupts until its driver attaches and requests an interrupt. Given > how we do our device probing, there's not really a chance to > 'downgrade' the FAST to non-FAST later with driver notification (we > can trivially downgrade what we do to ithread, but then the driver > might not actually work). Attaching the interrupt only at open time and detaching it at last-close time would work OK, and is needed anyway to handle timesharing of normal unshareable isa interrupts (RF_TIMESHARE is another problematic higher level flag, since it doesn't do anything to make the necessary timesharing actually work). Problems with this: - the console device now wants its interrupt enabled at all times, and doesn't tuen off the interrupt at the device level on close - programs like getty would keep devices opened and would have to be killed to let the interrupt wiring change - interrupt unwiring doesn't work right, partly due to supporting historical braindamage in ppbus. The interrupt thread should go away on the last detachment from it, but doesn't. ppbus sets up and tears down its interrupt for every user-level i/o, since its timesharing involves a sort of open/close for every i/o. RF_SHAREABLE is another problematic higher level flag. sio doesn't set it for the interrupt resource, so the interrupt should be unshareable, but interrupt sharing works anyway. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051029124828.C30731>