Re: Support for LOCK#

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

On Sep 10,  9:47am, Belvin Stephen E wrote:
> Subject: Support for LOCK#
> All:
>
> Recent and past discussions of LOCK# have caused me to think harder about
> operating on a PCI bus with one or more masters that support lock.

I'm glad to hear this.

> Section 3.6 of the PCI 2.1 specification discusses Exclusive Access to PCI
> target resources using the LOCK# signal.  It says (page 73, near the bottom
> of the page) 'The use of  LOCK# is not recommended for devices other than
> bridges or memory controllers that support system memory'.
>
> What is a target that doesn't support LOCK# supposed to do if an initiator
> tries to lock it?  Ignore the attempt and behave as though LOCK# was not
> asserted?  Tell the initiator the back off (retry, target-abort, ...)?

IMO, a target that doesn't support LOCK# shouldn't even bother wasting a
pin on LOCK#.  In that case, it effectively behaves the same it would it
LOCK# were not asserted.

> What are the responsibilities of an initiator that is trying to perform a
> locked transaction with a target that doesn't support LOCK#?

The initiator should not count on atomicity of accesses done with LOCK#
asserted.  Therefore, there was no value to asserting LOCK#, so nobody
would do this intentionally.

> TIA
>
> Steve Belvin

Monish Shah
Hewlett Packard
â
X	F