Date: Tue, 27 May 1997 13:39:33 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Bruce Evans <bde@zeta.org.au> Cc: gurney_j@resnet.uoregon.edu, current@FreeBSD.ORG Subject: Re: cvs commit: src/sys/sys interrupt.h src/sys/kern kern_intr.c Message-ID: <19970527133933.11160@x14.mi.uni-koeln.de> In-Reply-To: <199705271118.VAA05558@godzilla.zeta.org.au>; from Bruce Evans on Tue, May 27, 1997 at 09:18:52PM %2B1000 References: <199705271118.VAA05558@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 27, Bruce Evans <bde@zeta.org.au> wrote: > >driver's handler in turn. There is no provision to deal > >with Edge triggered shared interrupts, though. Your > >driver will have to make sure, that the interrupt pin > >sees a new Edge after you leave the multiplex handler, > >or you will never again see an IRQ. This is normally > >done by looping until the interrupt line has become > >inactive, and this loop should go into the low level > >(coded in assembler) interrupt code, IMHO ... > > No, the loop is best done in individual drivers. The low level > code can't read the interrupt pin, at least for the ICU case, > and drivers can more easily keep track of their state if they > do they loop themselves. The only reason to return to the But it doesn't suffice, that each driver loops as long as is responsible for the activation of the interrupt line. Before all devices have been serviced, the first one may have asserted the IRQ signal again, and if there is no loop over all devices, until none of them required service, this will quickly hang your system ... > low level is to give other interrupt handlers a chance to run, > which is only worth doing if all the drivers cooperate, but > none do. Hmmm, I was hoping for a way to do the multiplexing from a common pseudo interrupt handler. The original PCI shared interrupt code expected the driver's interrupt handler to return an indication of whether there was any work to do. The multiplexer would loop as long as at least one driver reported it was called for a reason ... :) I had been hoping that the low level code could be made to check a flag, which if set would require the ICU to be queried about the interrupt pin state. But I've got to admit, that it has been too long since I programmed an 8259, and that I don't remember if you could read out the level applied to some edge triggered IRQ pin ... (And you seem to tell me, that there is no way to do this ... Too bad!) How about adding a second type of interrupt multiplexer, which does expect the device's handler to return a status indicating whether this device caused the interrupt ... This multiplexer would only be installed for edge-triggered IRQ lines, and the faster one that just does a single poll pass over all devices would be used for PCI/EISA with level triggered interrupts ... ? Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970527133933.11160>