RE: Subsystem Vendor and Device IDs

["Kevin D. Davis" <kevind@ti.com>]

>  this could be done by subsystems agreeing on a space in the rom for each
>  type of device to read from. Like VGA from 000 PC Card from 010 SCSII 
from 020 etc.

It would have to be some other agreement.  I wonder if all could just use 
the same values.  One problem is that I2C is a master driven bus.  Not all 
devices could grovel in the ROM by themselves, whenever they wanted.

Kevin


----------
From:  Stephen A. Smith[SMTP:sas@corp.cirrus.com]
Sent:  Tuesday, July 23, 1996 3:15 PM
To:  pci-sig-request@znyx.com; kevind@ti.com
Subject:  RE: Subsystem Vendor and Device IDs


> From pci-sig-request@znyx.com Tue Jul 23 12:15:50 1996
> Return-Path: <pci-sig-request@znyx.com>
> Resent-From: pci-sig-request@znyx.com
> Resent-Date: Tue, 23 Jul 1996 09:40:52 -0500
> Subject: RE: Subsystem Vendor and Device IDs
> Encoding: 133 TEXT
> Resent-Message-Id: <"KMbct1.0.a97.xHHzn"@dart>
> X-Mailing-List: <pci-sig@znyx.com> archive/latest/3280
> X-Loop: pci-sig@znyx.com
> Precedence: list
> Resent-Sender: pci-sig-request@znyx.com
> To: Mailing List Recipients <pci-sig-request@znyx.com>
> Content-Length: 5693
> X-Lines: 134
>
> As notebook manufacturers, we have definite opinions about the "correct"
> method of implementing PCI subsystem IDs.
>
> 	1. Is it okay to allow our own BIOS to modify the values in the
> 	   Subsystem ID registers during bootup (through a custom mechanism,
> 	   not through a Configuration Write)?
> Yes and no.  But you have to ask how YOUR BIOS gets control after a power

> or dock event.  By power event, I mean if the OS tells you to go to your
> lowest power state and the system removes power from your chip.  If your
> BIOS is part of the system BIOS, then no problem.  But if you have a post

> time PCI BIOS, then you could be hosed.  Windows NT is not (probably) 
going
> to let your BIOS run after a power event.

unless the OS does a "complete" save and restore, the provided POST must be
run after any power state that allows context to be lost.  Otherwize the
post is not ever needed.


>
> 	2. Assuming the device was on a motherboard, would it be possible
> 	   for the system BIOS to be responsible for returning a unique
> 	   Subsystem ID value rather than querying the device directly
> 	   through a Configuration Read mechanism?
> Sure, but is Microsoft going to support a system BIOS function call that
> performs this function?  Would it work under Windows NT?  I personally 
like
> this one.  The system BIOS could return a list of the PCI devices and 
their
> bus numbers, that "belong" to the motherboard.  Note, that the docking
> station motherboard is sometimes not on bus 0, but belongs to the system
> motherboard.

nice but too complex for the time frame required. after any power state 
that
does state that context may be lost the device must be posted by the POST 
code and then a "restore" may be done by the OS. Unless the OS understands 
much more
than it does now this is going to end up as a requirement.

>
>
> Don't forget that in an ACPI and OS directed power management world, the
> system BIOS is not running the show.  MS will be groveling around in the
> config space pretty soon.
>
> Another suggestion is I2C ROMs.  I don't like this solution because every

> PCI device would need one.  With 3 PCI chips in the system, I would have 
3
> fairly useless chips taking up space.  It would be really nice for this
> implementation if we could have 1 serial ROM that all 3 PCI devices would

> share.

this could be done by subsystems agreeing on a space in the rom for each
type of device to read from. Like VGA from 000 PC Card from 010 SCSII from 
020 etc.

>
> Kevin
>
> ----------
> From:  havard scott[SMTP:havard@brooktree.com]
> Sent:  Monday, July 22, 1996 9:33 PM
> To:  Mailing List Recipients
> Cc:  dbaker@brooktree.com; larky@brooktree.com; jv@brooktree.com;
> pwood@brooktree.com
> Subject:  Subsystem Vendor and Device IDs
>
> I am making this post to solicit feedback on correct methods to
> implement the PCI subsystem IDs.
>
> First, let me say that I've read the PCI 2.1 specification, and I
> believe that I understand the specification of the PCI Subsystem ID
> configuration registers.
>
> The issue is that we have found it difficult to comply with both
> the PCI specification and Microsoft's Windows 95 certification
> requirements, and we are considering "bending the rules" of the
> PCI specification. I have two basic questions:
>
> 	1. Is it okay to allow our own BIOS to modify the values in the
> 	   Subsystem ID registers during bootup (through a custom mechanism,
> 	   not through a Configuration Write)?
>
> 	2. Assuming the device was on a motherboard, would it be possible
> 	   for the system BIOS to be responsible for returning a unique
> 	   Subsystem ID value rather than querying the device directly
> 	   through a Configuration Read mechanism?
>
> BACKGROUND
>
> Here is some background on these two questions. If the questions
> don't make sense, you might want to read this.	
>
> Windows 95 certification only requires
> that we return a unique value when Windows queries the hardware,
> but the PCI specification requires that either we return
> all zeroes, or  we return values "programmed during the
> manufacturing process or loaded from external logic (strapping
> options, serial ROMs, etc), prior to the system BIOS or any system
> software accessing the PCI Configuration Space." The problem is
> that returning all zeroes will not satisfy Microsoft, but
> the other options are either too expensive or impractical.
>
> We do have a parallel interface to a ROM, but we can't guarantee that
> we will have a ROM present. In other words, if our device is on the
> motherboard, then our BIOS code will go into the system BIOS ROM.
>
> So we have a couple of ideas as how to get around this limitation and
> still be compatible with the Windows 95.
>
>
> Idea #1
>
> Implement the Subsytem Device and Vendor ID PCI Config register through a
> writable register. This register would reset to a standard non-zero value
> (probably equal to the regular Device and Vendor ID values), and our
> custom BIOS init code would write a value custom to the board
> implementation. Note that this register is only writable through a
> device-specific mechanism, not through the PCI config space.
>
> The idea behind this approach is that only Windows 95 needs to see a
> board-implementation-specific value. Since our custom BIOS would run
> before Windows 95 booted, this requirement would be met. The concern
> is that some unforseen problem could happen because the system BIOS read
> subsytem ID values that were different from the values Window 95 
eventually
> read.
>
>
> Idea #2
>
> The second idea is to use our BIOS ROM to store the subsystem ID values.
> Config register reads of this register would be mapped into reads of
> a corresponding ROM address. If the ROM was not present, we would rely
> on the system BIOS to return the value rather than issuing a config
> cycle.
>
> This approach has a couple of issues with it. First, can we rely upon
> Windows 95 to always issue a PCI function call to system BIOS when
> reading the Subsystem IDs? Or will it attempt to program
> the core logic directly to issue a config read cycle to our device?
> Secondly, given that system BIOS has to be customized for each
> motherboard design anyway, is it reasonable to expect a level of
> customization whereby the system BIOS knows to emulate Configuration
> Reads to the Subsystem ID space of devices resident on the motherboard?
>
>
> That's all for now. I'd appreciate any suggestions.
>
>
> 		Havard Scott
> 		havard@brooktree.com
> 		512-349-3578
>
>
>
>
>


SA Smith


zTA