Subject: Re: PCI and subsystem IDs.
To: Chris G. Demetriou <email@example.com>
From: Soren S. Jorvang <firstname.lastname@example.org>
Date: 10/06/1998 22:28:19
>From the specification (2.1):
6.2.4. Miscellaneous Functions
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
(This hints somewhat at 'branding', BTW.)
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. Values in these registers are programmed
during the manufacturing process or loaded from external logic
(e.g., strapping options, serial ROMs, etc), prior to the
system BIOS or any system software accessing the PCI
Configuration Space. Devices loading these values from
external logic are responsible for guaranteeing the data is
valid before allowing reads to these registers to complete.
This can be done by responding to any accesses with a Retry
until the data is valid.
On Tue, Oct 06, 1998 at 11:50:34AM -0700, Chris G. Demetriou wrote:
> > From reading pcivar.h and pcireg.h, it appears that we don't even collect
> > that info.
> > I expect that we should. Comments?
> Perhaps. I've yet to see consistent enough usage and application of
> them to decide how to represent them.
> Specifically, the things i'm wondering are:
> (1) what is the namespace for subsystem vendor IDs? (I've heard "same
> as vendor IDs," but haven't had C&V quoted at me, so i'm
> skeptical. 8-)
'Subsystem Vendor IDs can be obtained from the PCI SIG [...]'
Whatever that means.
> (2) what is the namespace for subsystem IDs? I.e. is it per subsystem
> vendor, or per prod/vendor/subsystem_vendor?
'Values for Subsystem ID are vendor specific.'
Whatever that means.
I have two devices with non-zero sub-ID fields.
vendor product subsys subvendor
Matrox Millenium G200 0x102b 0x0521 0xff03 0x102b
Ensoniq AudioPCI 0x1274 0x5000 0x4c4c 0x4942
Matrox seems to support (1) above. They use the subsystem ID
for distinguishing between their numerous different cards
using the G200 core (same product ID).
0x4942 is not in the PCI SIG lists, and 0x4c4c seems rather
random. Ah well.
> The answers to those questions are necessary before anything 'useful'
> can be done around recording them in a consistent manner.
> There's also the issue that, in the largest share of devices i've
> seen, if they're present at all they're completely ignorable.
> There're only two cases i've heard of where paying attention to them
> are important, and of those, only one has a driver in the source tree.
Anyway, what is important in relation to NetBSD is whether
drivers need the sub IDs for matching/attachment, and I
believe that is not the case.
It seems to me that one driver should be sufficient for
any number of devices with different sub-IDs but the
same one (or more) product ID.
I think all this is necessary here is adding somewhat like
this little diff and letting the drivers sort it out.
--- src/sys/dev/pci/pcireg.h.orig Tue Oct 6 21:52:50 1998
+++ src/sys/dev/pci/pcireg.h Tue Oct 6 22:08:00 1998
@@ -283,6 +283,23 @@
#define PCI_MAPREG_IO_ADDR_MASK 0xfffffffc
+ * CardBus CIS register; contains a pointer to a CardBus CIS structure.
+#define PCI_CARDBUS_CIS_REG 0x28
+ * Subsystem identication register; contains a subsystem ID and
+ * a subsystem vendor ID.
+#define PCI_SUBID_REG 0x2c
+ * Expansion ROM base address register.
+#define PCI_ROMBASE_REG 0x30
* Interrupt Configuration Register; contains interrupt pin and line.
#define PCI_INTERRUPT_REG 0x3c