Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Mar 1995 11:43:29 -0800
From:      "Justin T. Gibbs" <gibbs@estienne.CS.Berkeley.EDU>
To:        se@MI.Uni-Koeln.DE (Stefan Esser)
Cc:        current@FreeBSD.org
Subject:   Re: Sharing interrupts with PCI devices? 
Message-ID:  <199503181943.LAA22949@estienne.cs.berkeley.edu>
In-Reply-To: Your message of "Fri, 17 Mar 1995 22:57:15 %2B0100." <199503172157.AA02658@FileServ2.MI.Uni-Koeln.DE> 

next in thread | previous in thread | raw e-mail | index | archive | help
>On Mar 17, 12:27, "Justin T. Gibbs" wrote:
>} Subject: Re: Sharing interrupts with PCI devices?
>} >
>} >PCI interrupts can be shared, but ISA 
>} >interrupts will have to be assigned
>} >uniquely as before.
>} >
>} 
>} Why can't we chain them?  I thought that the PCI spec allowed for PCI
>} devices to share ISA irqs.
>
>This would require further changes in 
>the ISA interrupt code.
>
>And ISA interrupts are Edge Triggered
>on most systems, and that isn't a good 
>base for shared interrupts ...
>
>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.

>
>} >The PCI code generally finds the IRQ
>} >line the PCI interrupt is routed to
>} >by a PCI BIOS call, or (as the current 
>} >BSD code does) in a PCI configuration
>} >space register.
>} 
>} I take it that both methods return the same result.
>
>Yes. Else there was something severely
>wrong with your BIOS.
>
>} >The NCR driver doesn't install an 
>} >interrupt handler if the IRQ found 
>} >this way is '0'. It works in a polled
>} >mode instead. There is nothing to 
>} >prevent you from making the driver 
>} >configuration depend on the IRQ being
>} >specified. So it's in fact quite easy
>} >to selectively disable the aic7870 in 
>} >the above mentioned case ...
>} 
>} So how do I enforce an irq?  Can I just specify it in the
>} kernel config file?  My irq comes out as 10 for both the
>} onboard controller and the separate 294x.
>
>It is possible to specify the IRQ in 
>the kernel config file, but you don't
>want to do that.
>
>You expect the PCI BIOS to do the 
>complete PCI chip set initialisation,
>including the PCI Int to IRQ routing.
>
>The BIOS puts the IRQ value it has
>prepared for some PCI device into a 
>special configuration space register,
>were the driver reads it.
>
>The Int to IRQ routing is implemented 
>quite differerently in the many PCI 
>chip sets currently on the market. 
>
>Most let you specify one IRQ for the 
>PCI IntA line, but completely ignore
>IntB to IntD.
>
>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.

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?

>
>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

--
Justin T. Gibbs
==============================================
TCS Instructional Group - Programmer/Analyst 1
  Cory | Po | Danube | Volga | Parker | Torus
==============================================



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503181943.LAA22949>