[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Support for LOCK#
- To: Mailing List Recipients <pci-sig-request@znyx.com>
- Subject: Support for LOCK#
- From: "Belvin Stephen E" <belvin_stephen_e@smtp2.space.honeywell.com>
- Date: 10 Sep 1996 09:47:02 -0400
- Resent-Date: 10 Sep 1996 09:47:02 -0400
- Resent-From: pci-sig-request@znyx.com
- Resent-Message-Id: <"dFax33.0.gU2.33NDo"@dart>
- Resent-Sender: pci-sig-request@znyx.com
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, ...)?
What are the responsibilities of an initiator that is trying to perform a
locked transaction with a target that doesn't support LOCK#?
TIA
Steve Belvin
á Œ y