Messages in this thread | | | Date | Fri, 3 Sep 1999 20:32:43 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: Shared interrupt (lack of) handling |
| |
On Thu, 2 Sep 1999, David Schleef wrote:
> On Thu, Sep 02, 1999 at 09:41:48PM +0200, Gerard Roudier wrote: > > > > > > I'd vote for changing the return value of the interrupt handlers to > > > (int), and return a I_DID_SOME_STUFF flag. That way, if none of the > > > > This does not make sense at all for PCI. > > > > In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS! Synchronisation events > > are PCI TRANSACTIONS in the context of ordering rules defined by the > > specs, but unfortunately only a few hardware implemented that stuff > > correctly. People that think interrupts as synchronisations events are not > > able to write PCI device drivers that will work reliably in presence of > > posted transactions. A PCI interrupt just kicks the driver code that has > > then to synchronize correctly with de device, both using PCI transactions > > and relying on PCI ordering rules (or the subset available on the involved > > hardware). > > > I appear to be missing something. What do PCI synchonization issues > have anything to do with a driver giving the OS hints? The delivery > of interrupts to the handlers would not change, but only that messages > *might* get printk'd if an interrupt occurs and no handler thinks that > the interrupt belongs to it. How often do spurious interrupts occur BTW, "share" is kind of opposite of "belong". > in a correctly functioning computer that shares interrupts between, > say, a NIC and SCSI card?
An PCI interrupt that occurs and no device (sharing the INT line) having things to do may happen in PCI without being a spurious interrupt (even if this is probably a rare situation). Your statement let me think that your knowledge on PCI is just ISA+.
> One thing that you could do with the I_DID_SOME_STUFF flag is use the > statistics to reorder the execution of interrupt handlers so that the > device that causes the most interrupts gets called first. Might be > cool, difficult to tell.
You _must_ call all interrupt handlers that requested the same IRQ when this IRQ is raised. So your flag does not optimize anything.
Gérard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |