Re: Support for LOCK#

[Andrew Crosland <crosland@radstone.co.uk>]

>
> 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.
>
> 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, ...)?

LOCK# is an optional pin. A target that doesn't support LOCK# probably wouldn't
implement the pin and would have no knowledge that an initiator is trying to
lock it. It must respond normally.

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

If it knows the target doesn't support LOCK# then it shouldn't attempt a locked
transaction and expect it to work.

> TIA
>
> Steve Belvin
>
>
>
>

ã
H7