Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <current-users@netbsd.org>
From: Greg A. Woods <woods@most.weird.com>
List: current-users
Date: 10/08/1998 21:59:54
[ On Thu, October 8, 1998 at 18:19:40 (-0700), Curt Sampson wrote: ]
> Subject: Re: Another changer, another changer problem
>
> On Thu, 8 Oct 1998, Greg A. Woods wrote:
> > Ordinary PCI is limited to 4 slots per bus....
> 
> Evidently not. At least, ASUS has no trouble producing five-slot
> motherboards. See
> 
>     http://www.asus.com/products/Specs/MB/p6np5-Spec.asp
 
You mean this one that says:

	Bus Architecture

	4 32-bit PCI slots 
	1 Asus MediaBus (Revision 2.0) Slot. 
	3 16-Bit ISA Slots. 

????????
 
> > ...(and it seems 4 logical units
> > per slot, though I don't yet know much about this part of the spec.).
> 
> No. A package may have up to eight functions in it.

Nine, actually, though I admit I didn't really pay close attention to
the 21150 specs previously and notice this until today....

> I can't even figure out how you intend to map controllers to the
> N in /dev/cN... Perhaps you could explain how this would occur on
> typical PCI bus systems.

Other than the simple one-controller per slot model, the only real way
to handle PCI dynamically is by drawing a tree structure.  Every time
you put in a bridge chip you might need to branch the structure.
Without worrying yet about silly things like major/minor numbers (which
*can* go completely away with devfs anyway), this could lead to:

	pci_s0--pci_s0.1
	        pci_s0.2
	        pci_s0.3--pci_s0.3.d1
	                  pci_s0.3.d2
	                  pci_s0.3.d3
	                  pci_s0.3.d4
	                  pci_s0.3.d5
	                  pci_s0.3.d6
	                  pci_s0.3.d7
	                  pci_s0.3.d8
	        pci_s0.4--pci_s0.4.s0
	                  pci_s0.4.s1--pci_s0.4.s1.d0
	                               pci_s0.4.s0.d1
	                               pci_s0.4.s0.d2
	                               pci_s0.4.s0.d3
	                               pci_s0.4.s0.d4
	                               pci_s0.4.s0.d5
	                               pci_s0.4.s0.d6
	                               pci_s0.4.s0.d7
	                               pci_s0.4.s0.d8
	                  pci_s0.4.s2
	                  pci_s0.4.s3
	pci_s1
	pci_s2
	pci_s3-- ... and so on

where "sN" is a physical slot, and "dN" is a device on a card.

Any of the above terminal nodes could branch to a SCSI bus.

Perhaps the problem is trying to make a "generic" i386 kernel in this
scenario.  In any given CompactPCI system you'd be unlikely to widely go
adding more bus extenders without a lot of due consideration, so the
only thing you really have to worry about is plugging in a non-system
card that might have mezzanine connectors off on a bridge....

This is why I keep alluding to moving to sparse data structures to
define the device configuration space...

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>