Date: Tue, 21 Mar 1995 01:16:56 +0100 From: se@MI.Uni-Koeln.DE (Stefan Esser) To: current@FreeBSD.org Subject: Re: Sharing interrupts with PCI devices? Message-ID: <199503210016.AA05446@FileServ1.MI.Uni-Koeln.DE> In-Reply-To: "Justin T. Gibbs" <gibbs@estienne.cs.berkeley.edu> "Re: Sharing interrupts with PCI devices?" (Mar 18, 11:43)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 18, 11:43, "Justin T. Gibbs" wrote:
} Subject: Re: Sharing interrupts with PCI devices?
} >Shared interrupts are a requirement for
} >PCI, if you want to deal with 4 channel
} >Ethernet cards, or with PCI to PCI bridges
} >in general.
} >
} >The PCI shared interrupt code can be
} >implemented architecture independent (i.e.
} >is not bound to PC compatible hardware),
} >while moving that code into the ISA tree
} >means it sure can't be used for other
} >machines with PCI bus, and will have to
} >be reimplemented.
} >
} >I can live without shared ISA interrupts,
} >but we need them for PCI.
}
} I don't see why the two are mutually exclusive. I'd like
} to be able to share EISA interrrupts too.
Yes, nothing keeps you from adding
this for EISA devices ...
In fact, the PCI interrupt sharing
will probably be directly applicable
to EISA devices, too.
The only new requirement is, that the
interrupt handler returns '0' in case
that device didn't cause the interrupt,
a '1' if it did ...
We don't have any EISA system to test
this on, but the PCI interrupt code
will use a two layer approach:
1) If only one interrupt is assigned to
some IRQ, then the current code will
be used.
2) If interrupts are shared, then there
is a generic handler, which will call
each the handler for each device, after
masking those device classes interrupts.
(I.e. IRQ9 is used for DEC Ethernet and
NCR SCSI: The 'ed' handler will be called
with netmask, the NCR handler with biomask
applied.)
This results in low overhead operation
in the non shared case, and in interrupts
masked for as short a period of time as
possible in the shared case.
*** *** *** *** *** *** *** *** *** *** ***
I will apply the PCI SHARED INTERRUPT patch
tomorrow. All PCI device drivers will have
been checked to conform to the return value
convention described above !
EISA devices will work with shared interrupts,
too, if their drivers are patched accordingly.
Somebody else will have to patch their interrupt
handlers and write some simple eisa_map_int()
function, similar to the NEW pci_map_int(), that
I'm going commit to -current tomorrow.
*** *** *** *** *** *** *** *** *** *** ***
} >If both your AIC devices are mapped
} >to use IRQ 10 (you are using the
} >pci_map_int() call, which will use
} >the BIOS supplied value), then this
} >is what you specified in the BIOS.
} >
} >I don't know which motherboard you
} >use, but it may help, if you send
} >me the boot message log.
}
} I'm using an Intel Altair motherboard. Its something they ship out
} to special customers or something. Its on loan from an Intel employee.
Hmm, I still don't know, whether that
onboard SCSI chip is a PCI device (i.e.
can be configured as such). If it is on
ISA, then you can specify the IRQ to use
in the kernel config file. If it is hard
wired to some IRQ line, then you ought
to be able to set the Adaptec card to use
another IRQ.
} One other funny thing. If you look at how aic7870.c is now, I call
} pci_map_int after I scan the bus. It would make more sense to map
} the interrupt handler (and deal with interrupt collisions) before
} scanning the bus (ahc_attach). Unfortunately, when I call pci_map_int
} first, the bus probe hangs. Its almost as if the code is relying on
} interrupts now that a handler is installed but since this is during
} boot/probe time, interrupts are disabled. Where it is now, works for
} one card. The ncr driver maps the interrupt first. Any ideas?
Sorry. I'm very busy right now ...
If the Adaptec signals an interrupt
condition before being initialised,
then I'd understand, why the bus probe
would appear to hang if pci_map_int()
was called forst:
The interrupt handler for the Adaptec
would be called immediately, would find
nothing to do, return, and because of PCI
interrupts being Level triggered, this
would result in another call of the same
interrupt handler immediately again.
Might help to printf() the interrupt status
register on entry to the IRQ handler ...
This way you would detect the infinite
interruptt handler "loop" and possibly the
cause. (Switching to Edge triggered interrupts
might be a preliminary workaround.)
Regards, STefan
--
Stefan Esser Internet: <se@ZPR.Uni-Koeln.DE>
Zentrum fuer Paralleles Rechnen Tel: +49 221 4706019
Universitaet zu Koeln FAX: +49 221 4705160
Weyertal 80
50931 Koeln
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503210016.AA05446>