From owner-freebsd-hackers  Sat Nov 16 13:39:32 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA21865
          for hackers-outgoing; Sat, 16 Nov 1996 13:39:32 -0800 (PST)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA21852;
          Sat, 16 Nov 1996 13:39:22 -0800 (PST)
Received: from x14.mi.uni-koeln.de (annexr3-13.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA13806
  (5.67b/IDA-1.5); Sat, 16 Nov 1996 22:39:16 +0100
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id WAA00542; Sat, 16 Nov 1996 22:38:33 +0100 (MET)
Message-Id: <199611162138.WAA00542@x14.mi.uni-koeln.de>
Date: Sat, 16 Nov 1996 22:37:13 +0100
From: se@freebsd.org (Stefan Esser)
To: bde@zeta.org.au (Bruce Evans)
Cc: bde@zeta.org.au, se@freebsd.org, hackers@freebsd.org, mrcpu@cdsnet.net
Subject: Re: IRQ sharing on PCI?
References: <199611161657.DAA23158@godzilla.zeta.org.au>
X-Mailer: Mutt 0.49-PL10
Mime-Version: 1.0
In-Reply-To: <199611161657.DAA23158@godzilla.zeta.org.au>; from Bruce Evans on Nov 17, 1996 03:57:21 +1100
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Nov 17, bde@zeta.org.au (Bruce Evans) wrote:
> >This means that there are in fact four PCI Int lines, but
> >most PCI cards will only use Int A. multi-function devices
> >will use Int A and Int B, if two functions are implemented
> >(see the AMD SCSI+Ethernet Combo chip), or all four lines
> >if there are four functions on a chip (announced 4 channel
> >Ethernet cards). And if you are using a PCI to PCI bridge 
> >(current 4 channel Ethernet cards and the AH3940 or PCI bus
> >extender boxes, for example), then the PCI Int lines used 
> >will depend on the slots used on the secondary side of the
> >PCI bridge. (The scheme used is meant to randomize PCI Int 
> 
> But these aren't typical :-).  Now that Pentiums and PCI are

Well, we are lucky that the PCI-SIG didn't decide to only
support the "typical" PC ... I wasn't interested in the 
result, if they had ... :)

> common in typical (cheap) systems, I guess that a typical
> PCI system has 0 or 1 (unused) PCI interrupts depending on

I assume you mean IRQs, not PCI interrupts ?

> whether vga0 has one :-].  Why aren't PCI interrupts used
> for motherboard i/o, at least optionally?

Hmmm, I don't quite understand this question.

I surely would prefer, if PCI was defined to use a reasonable
interrupt controller, seperate from the ISA PIC. But in order
to support fully ISA compatible PCI cards (for example some
BusLogic SCSI controllers and some Eternet cards, well and all
the VGA cards ...) they didn't say anything about interrupts,
except that they must be shareable.

> BTW, `pciconf -r' dumps core after printing the usage message.

Really ? It was supposed to panic your system  :)

The following patch fixes this (and adds printing of the header
type register, which will be required for yet to be released 
PCI chips).

Regards, STefan

Index: /usr/src/usr.sbin/pciconf/pciconf.c
===================================================================
RCS file: /usr/cvs/src/usr.sbin/pciconf/pciconf.c,v
retrieving revision 1.1.1.1
diff -C2 -r1.1.1.1 pciconf.c
*** pciconf.c	1996/10/22 20:27:47	1.1.1.1
--- pciconf.c	1996/11/16 21:23:14
***************
*** 54,57 ****
--- 54,58 ----
  		"\t%s [-r|-w] [-bh] sel addr [value]\n",
  		argv0, argv0);
+ 	exit (1);
  }
  
***************
*** 132,139 ****
  
  	for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) {
! 	    printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x\n",
  		   p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func, 
  		   p->pc_class >> 8, p->pc_subid,
! 		   p->pc_devid, p->pc_class & 0xff);
  	}
  }
--- 133,140 ----
  
  	for (p = conf; p < &conf[pc.pci_len / sizeof conf[0]]; p++) {
! 	    printf("pci%d:%d:%d:\tclass=0x%06x card=0x%08lx chip=0x%08lx rev=0x%02x hdr=0x%02x\n",
  		   p->pc_sel.pc_bus, p->pc_sel.pc_dev, p->pc_sel.pc_func, 
  		   p->pc_class >> 8, p->pc_subid,
! 		   p->pc_devid, p->pc_class & 0xff, p->pc_hdr);
  	}
  }