RE: Subsystem IDs and their meaning

["Kimmery, Clifford (FL51)" <kimmery@space.honeywell.com>]

> ----------
> From: 	Dan Mick[SMTP:dan.mick@West.Sun.COM]
> Sent: 	Monday, January 05, 1998 7:18 PM
> To: 	dan.mick@West.Sun.COM; kimmery@fl51mail.space.honeywell.com
> Cc: 	pci-sig@znyx.com
> Subject: 	RE: Subsystem IDs and their meaning
> 
> 
> > From: "Kimmery, Clifford (FL51)" <kimmery@space.honeywell.com>
> > To: "'Dan Mick'" <dan.mick@West>
> > Cc: "'PCI SIG'" <pci-sig@znyx.com>
> > Subject: RE: Subsystem IDs and their meaning
> > Date: Mon, 5 Jan 1998 19:14:22 -0500 
> > 
> > I have to quibble with your allocation of 32 bits or 64 bits to
> > 'unique-in-all-the-world' identification.
> >
> > Since the vendor ID portions
> > of the device and subsystem identification fields are uniquely
> assigned
> > by the PCI SIG and are not available for arbitrary vendor use, the
> > dynamic range of the 'unique-in-all-the-world' identification is
> limited
> > to 16 bits for case 1) or 32 bits for case 2), unquestionably a more
> > limited resource in either case.
> >
> > I must vote for 2) since it provides a much larger address space.  A
> > large vendor developing multiple PCI products per year over a number
> of
> > years could conceivably exceed a 16 bit address space.  I doubt that
> > they could exceed 32 bits during the life of the PCI bus unless they
> > used a particularly inefficient encoding scheme.
> 
> First, huh?  I didn't allocate anything; I'm asking what you think the
> spec
> allocated. 
> 
The statements regarding 32 bits of config space and 64 bits of config
space implied that all of those bits were available for vendor use.  I
was simply pointing out that the vendor fields could not contain
arbitrary values.  

> Second, I don't know what "more limited in either case" means; there's
> clearly a comparison between two things, but "either" seems to negate
> that comparison.  
> 
The comparison is between the 32 bits of subsystem config space and the
16 bits usable by the vendor (case 1) or the 64 bits of subsystem plus
device config space and the 32 bits usable (case 2).

> But regardless: If any one vendor makes 65537 different PCI devices
> before PCI disappears from the planet, I'll be amazed.  Moreover, I
> believe that limitation already exists, right?  As far as I know,
> everyone agrees that a different device from the same vendor *must*
> have a different 16-bit DID, which is independent of what happens in
> the subsystem field.
> 
You are probably correct that a single vendor is unlikely to make 65536
different PCI devices.  However, since I interpreted case 1 as using the
subsystem ID field to duplicate the information in the device ID field,
I was not willing to assume that a single vendor would not be capable of
making 65535 different PCI subsystems over the life of the bus.
Assumptions like that have caused the Y2K problems.

> > 
> > Cliff Kimmery
> > Honeywell Inc.
> > kimmery@space.honeywell.com
> > 
> > > ----------
> > > From: 	Dan Mick[SMTP:dan.mick@West.Sun.COM]
> > > Sent: 	Monday, January 05, 1998 2:47 PM
> > > To: 	Mailing List Recipients
> > > Subject: 	Subsystem IDs and their meaning
> > > 
> > > Hi, all.  There seems to be a difference of opinion about the
> > > interpretation of the spec WRT Subsystem IDs.  I've asked Warren
> > > Questo at Intel to help clarify, but have gotten no response as
> yet.
> > > 
> > > Can I run a quick opinion poll?
> > > 
> > > How many of you think either of the below?  (I believe them to be
> > > mutually-exclusive, so you can't think both.):
> > > 
> > > 1) The Subsystem Vendor ID and Subsystem ID can be used, by
> > > themselves, as the only pieces of information to uniquely identify
> a
> > > given PCI device (i.e. 32 bits of config space is a
> > > unique-in-all-the-world identifier for "this device in this
> > > subsystem").
> > > 
> > > 2) The Subsystem Vendor ID and Subsystem ID can be used only in
> > > conjunction with the Vendor ID and Device ID to uniquely identify
> a
> > > given PCI device. (i.e. 64 bits of config space is a
> > > unique-in-all-the-world identifier for "this device in this
> > > subsystem".)
> > > 
> > > 
> > > Raise your e-hands, please, 1 or 2 (privately or publicly, as you
> > > like, and I'll summarize, anonymously or otherwise, as you like).
> > > 
> > > ---
> > > 
> > > Here's some background material if you want to read on or are
> unclear
> > > about just what I mean:
> > > 
> > > 
> > > INTRODUCTION:
> > > 
> > > We've recently run into a disagreement about spec interpretation
> for
> > > the Subsystem fields in the PCI config space header.
> > > 
> > > Throughout this discussion I'll refer to the pair of numbers
> > > Vendor ID and Device ID as "normal ID" and the pair of numbers 
> > > Subsystem Vendor ID and Subsystem ID as "subsystem ID".
> > > 
> > > BACKGROUND:
> > > 
> > > We at Sun seem to have the opinion that subsystem ID is used to
> > > indicate a
> > > strictly-more-specific device identification that is unique,
> > > per-device, just as the normal ID is unique per-device.  The
> > > implication is that subsystem ID is completely sufficient for
> finding
> > > the "best" driver for a device, if present, and that if there is
> no
> > > subsystem-specific driver, the subsystem info can be ignored and
> the
> > > normal ID used to bind a driver.
> > > 
> > > NEW INFO CAUSING PROBLEM:
> > > 
> > > A vendor has produced a motherboard which includes two
> > > very-dissimilar PCI devices (a graphics chip and an Ethernet
> chip),
> > > both of which have subsystem IDs.  However, they have exactly the
> > > *same* subsystem ID....the one which represents this particular
> > > motherboard (motherboard vendor's vendor ID, and a number
> indicating
> > > the motherboard in Subsystem ID).  They claim this is PCI 2.1- and
> > > PC97-compliant.
> > > 
> > > 
> > > PROBLEM:
> > > 
> > > The interpretation of the meaning of the values in the subsystem
> ID
> > > is the issue, not the format (the "semantics" rather than the
> > > "syntax",
> > > if you will).
> > > 
> > > The P1275 Bus Binding for PCI requires, in the absence of generic
> > > names, the node name (in the "name" property and in the /devices
> tree
> > > in Solaris) to be set from the subsystem ID if present, otherwise
> to
> > > be set from the normal ID.  While this will still work, strictly
> > > speaking, for this system, since the unit-address is different
> > > for the two devices, it will:
> > > 
> > > 1) certainly be a confusing set of nodes and /devices entries, as
> > > they'll both say "pciVVVV,DDDD@<unit-address>" using the same
> > > VVVV,DDDD, albeit different unit-addresses, and prtconf will show
> the
> > > device node name as "pciVVVV,DDDD".
> > > 
> > > 2) prevent the binding of a different driver for this particular
> > > device, made up of a video-chip-in-a-OEM-mumblefoo-motherboard,
> > > since the driver binding will be done either from the subsystem ID
> > > (which we'll have to avoid binding, since it's identical for two
> > > devices which obviously have different drivers), or the vendor ID
> > > (which loses the information about the subsystem).
> > > 
> > > 1) is inconvenient.  2) may be a problem.
> > > 
> > > I've looked at the driver binding for Microsoft Windows 95 (and
> assume
> > > it's the same for NT).  They seem to create an identifier which 
> > > includes both subsystem and normal IDs (along with Revision) so
> that
> > > the right driver can be bound if there is a specific driver.
> > > 
> > > INTENDED SUBSYSTEM SEMANTICS:
> > > 
> > > The PCI 2.1 spec isn't very helpful (see quote [1] below).
> > > 
> > > PC97 is similarly unhelpful; it merely says that they're required
> to
> > > be nonzero, and says some things about when they must be valid.
> > > 
> > > A later PCISIG ECN changes these from "optional" to "required", at
> > > several PCISIG members' request (Microsoft and DEC were big
> > > proponents).  I'm not certain of the status of this ECN but there
> are
> > > some quotes below at [2].
> > > 
> > > The PCI 2.1 spec certainly doesn't make it clear what the point of
> > > Subsystem ID is.  On the one hand, I can see the point that "a
> > > subsystem"
> > > is naturally interpreted as "a plug-in card" or "a motherboard".
> > > Think,
> > > for instance, about a commonly-found Ethernet card that has a
> PCI-PCI
> > > bridge chip and four identical DEC Ethernet PCI devices behind the
> > > bridge.
> > > What should the subsystem ID for these five devices be?  Should it
> 
> > > indicate the plug-in card, or the
> plug-in-card-plus-the-chip-function?
> > > (i.e. would you expect to be able to use the subsystem ID alone to
> > > determine the proper driver for each of the five PCI devices)?
> > > 
> > > It seems much clearer in the case of the two-wildly-different
> devices
> > > on the same motherboard, but I'm not clear.
> > > 
> > > On the other hand, while PCI 2.1 isn't very clear, the ECN says
> > > "to allow explicit driver determination for a specific PCI device"
> > > and "OS vendors can then use SVID and SID fields to specifically
> load
> > > the correct driver", both of which seem to support the notion
> > > that subsystem ID should be enough on its own to find a driver.
> > > 
> > > 
> > > ----
> > > 
> > > [1] From PCI 2.1:
> > > 
> > > Subsystem Vendor ID and Subsystem ID
> > > 
> > > These registers are used to uniquely identify the add-in board or
> > > subsystem where the PCI device resides.  They provide a mechanism
> for
> > > add-in card vendors to distinguish their cards from one another
> even
> > > though the cards may have the same PCI controller on them (and,
> > > therefore, the same Vendor ID and Device ID).
> > > 
> > > Implementation of these registers is optional and an all zero
> value
> > > indicates that the device does not support subsystem
> identification.
> > > Subsystem Vendor IDs can be obtained from the PCI SIG and are used
> to
> > > identify the vendor of the add-in board or subsystem.  Values for
> > > Subsystem ID are vendor specific.
> > > 
> > > 
> > > 
> > > [2] From PCI ECN "Subsystem Vendor ID and Subsystem ID required"
> > > 
> > > 
> > > 1.1.    Clarification / Motivation 
> > > 
> > > The intent of the Subsystem Vendor ID (SVID) and Subsystem ID
> (SID)
> > > is to allow explicit driver determination for a specific PCI
> device.
> > > These optional fields provide a standard mechanism to enable
> vendors
> > > to differentiate their designs. Since they are optional, few
> > > implementations use them. The problem exists when one PCI device
> is
> > > used in multiple designs. This variable device causes the
> > > configuration software to use heuristics as to which specific
> > > operating system driver to load.  This non-precise approach does
> lead
> > > to system anomalies.
> > > 
> > > The impetus of this ECR is to require these fields on all PCI
> devices
> > > with the exclusion of core logic chipsets, bridges, and legacy
> system
> > > devices. Specifically PCI devices that have a base class 6, with
> > > subclass 0-4 (0,1,2,3,4) and base class 8 subclass 0-3 (0,1,2,3)
> are
> > > excluded from this requirement. Core logic chipsets, bridges, and
> > > legacy system devices are excluded because these devices use
> existing
> > > operating system bus drivers, device dependent layers (i.e. HAL),
> or
> > > require no drivers for normal operation. All other PCI devices are
> > > required to implement the SVID and SID registers so that they can
> be
> > > used by different vendors in multiple designs.
> > > 
> > > OS vendors can then use SVID and SID fields to specifically load
> the
> > > correct driver, allowing IHVs to differentiate their products even
> > > though they are using the same silicon.
> > > 
> > > 
> > > 
>