3−3
3.4.2 PCI Bus Lock (LOCK)
The bus-locking protocol defined in the PCI Local Bus Specification is not highly recommended, but is provided on
the controller as an additional compatibility feature. The PCI LOCK
signal can be routed to the MFUNC4 terminal by
setting the appropriate values in bits 19−16 of the multifunction routing register. See Section 4.30, Multifunction
Routing Register,
for details. Note that the use of LOCK is only supported by PCI-to-CardBus bridges in the
downstream direction (away from the processor).
PCI LOCK
indicates an atomic operation that may require multiple transactions to complete. When LOCK is asserted,
nonexclusive transactions can proceed to an address that is not currently locked. A grant to start a transaction on
the PCI bus does not guarantee control of LOCK
; control of LOCK is obtained under its own protocol. It is possible
for different initiators to use the PCI bus while a single master retains ownership of LOCK
. Note that the CardBus
signal for this protocol is CBLOCK
to avoid confusion with the bus clock.
An agent may need to do an exclusive operation because a critical access to memory might be broken into several
transactions, but the master wants exclusive rights to a region of memory. The granularity of the lock is defined by
PCI to be 16 bytes, aligned. The LOCK
protocol defined by the PCI Local Bus Specification allows a resource lock
without interfering with nonexclusive real-time data transfer, such as video.
The PCI bus arbiter may be designed to support only complete bus locks using the LOCK
protocol. In this scenario,
the arbiter does not grant the bus to any other agent (other than the LOCK
master) while LOCK is asserted. A
complete bus lock may have a significant impact on the performance of the video. The arbiter that supports complete
bus lock must grant the bus to the cache to perform a writeback due to a snoop to a modified line when a locked
operation is in progress.
The controller supports all LOCK
protocol associated with PCI-to-PCI bridges, as also defined for PCI-to-CardBus
bridges. This includes disabling write posting while a locked operation is in progress, which can solve a potential
deadlock when using devices such as PCI-to-PCI bridges. The potential deadlock can occur if a CardBus target
supports delayed transactions and blocks access to the target until it completes a delayed read. This target
characteristic is prohibited by the PCI Local Bus Specification, and the issue is resolved by the PCI master using
LOCK
.
3.4.3 Loading Subsystem Identification
The subsystem vendor ID register (PCI offset 40h, see Section 4.26) and subsystem ID register (PCI offset 42h, see
Section 4.27) make up a doubleword of PCI configuration space for function 0. This doubleword register is used for
system and option card (mobile dock) identification purposes and is required by some operating systems.
Implementation of this unique identifier register is a PC 99/PC 2001 requirement.
The controller offers two mechanisms to load a read-only value into the subsystem registers. The first mechanism
relies upon the system BIOS providing the subsystem ID value. The default access mode to the subsystem registers
is read-only, but can be made read/write by clearing bit 5 (SUBSYSRW) in the system control register (PCI offset 80h,
see Section 4.29). Once this bit is cleared, the BIOS can write a subsystem identification value into the registers at
PCI offset 40h. The BIOS must set the SUBSYSRW bit such that the subsystem vendor ID register and subsystem
ID register is limited to read-only access. This approach saves the added cost of implementing the serial electrically
erasable programmable ROM (EEPROM).
In some conditions, such as in a docking environment, the subsystem vendor ID register and subsystem ID register
must be loaded with a unique identifier via a serial EEPROM. The controller loads the data from the serial EEPROM
after a reset of the primary bus. Note that the SUSPEND
input gates the PCI reset from the entire core, including the
serial-bus state machine (see Section 3.8.5, Suspend Mode, for details on using SUSPEND
).
The controller provides a two-line serial-bus host controller that can interface to a serial EEPROM. See Section 3.6,
Serial-Bus Interface,
for details on the two-wire serial-bus controller and applications.
