Re: Delayed Xaction and LOCK#

["Monish Shah" <monish@mcsy2.fc.hp.com>]

On Aug 26,  3:41pm, Richard Walter wrote:
....

> > BTW, I don't think it is possible to do locked transactions as delayed
> > transactions....
>
> Sure it's possible to do locked tranactions as delayed transactions.  The
> first sentence of section 3.3.3.3.5.  (pg.  52) reads "A locked transaction
> can be completed using delayed transaction termination."  The essential
> difference between a delayed transaction response and a normal retry
> response is that the target which is doing the delayed transaction
> considers itself locked even though the master doesn't think that he got
> the lock.  And the target (which now is locked) cannot enqueue any more
> transactions until the delayed transaction does complete.

Ah, yes.  I forgot about the PCI resource lock.  I was thinking in terms of
bus lock, which is how LOCK# tends to get implemented in real life.

While we're on the topic, I'd like to point out that LOCK# support is
optional for host bridges and PCI to PCI bridges are not required to
support LOCK# going from the secondary bus to the primary bus.  Therefore,
use of LOCK# should be avoided if at all possible.

> > Monish Shah
> > Hewlett Packard
>
> -Richard Walter
> rwalter@auspex.com

Monish Shah
Hewlett Packard
�
hV