From owner-freebsd-current Sat Mar 18 11:43:43 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA21946 for current-outgoing; Sat, 18 Mar 1995 11:43:43 -0800 Received: from estienne.cs.berkeley.edu (estienne.CS.Berkeley.EDU [128.32.42.147]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id LAA21940 for ; Sat, 18 Mar 1995 11:43:42 -0800 Received: from localhost (localhost [127.0.0.1]) by estienne.cs.berkeley.edu (8.6.9/8.6.9) with SMTP id LAA22949; Sat, 18 Mar 1995 11:43:30 -0800 Message-Id: <199503181943.LAA22949@estienne.cs.berkeley.edu> X-Authentication-Warning: estienne.cs.berkeley.edu: Host localhost didn't use HELO protocol To: se@MI.Uni-Koeln.DE (Stefan Esser) cc: current@FreeBSD.org Subject: Re: Sharing interrupts with PCI devices? In-reply-to: Your message of "Fri, 17 Mar 1995 22:57:15 +0100." <199503172157.AA02658@FileServ2.MI.Uni-Koeln.DE> Date: Sat, 18 Mar 1995 11:43:29 -0800 From: "Justin T. Gibbs" Sender: current-owner@FreeBSD.org Precedence: bulk >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: > 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 ==============================================