RE: Subsystem IDs and their meaning

[Dan Mick <dan.mick@West.Sun.COM>]

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

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.  

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.


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