X3T9.2/89-110 Rev 0 To: X3T9.2 Committee (SCSI) From: Gerry Houlder Imprimis Subject: Target Initiated SDTR Message Control We have customers that want synchonous transfers and want the target to initiate the negotiation for synchronous permission. Their host adaptor won't even consider initiating the SDTR message - if the target doesn't initiate it, synchronous agreement won't happen. We have other customers that want synchronous transfers but their host can't handle target initiated SDTR messages - we must wait for them to initiate it. This causes unique code versions. A better way to do this is to add a bit to a MODE SELECT page to make the feature initiator programmable. With saveable mode pages, the information survives resets and power cycles very nicely and can be customized with very little effort and bother on behalf of the customer. The only hole in this scheme is what to do before the disk is spun up so that saved values are available. This can be covered by designing the target so that it will not initiate a message exchange until the disk becomes ready. Since the only data transfers that can be done before the disk is ready are for the INQUIRY and REQUEST SENSE commands, doing asynchronous transfers won't cause a big performance problem. This proposal does just that - it adds a bit (Allow Target Initiated SDTR Message) to the Control Mode Page (0Ah). This seems to be the right page because it is page common to all device types, it is related to the other functions done on the page, it is a new page (so this won't break many current imple- mentations), and there is plenty of room to define another bit. We feel strongly about the need for this ability, so strongly that it SHOULD BE A PART OF SCSI-2. The rest of this proposal points out the changes that are needed to incorporate this into the SCSI standard. Page numbers and section numbers referred to are taken from Rev. 10 of the SCSI-2 draft standard. Text shown in brackets [] are explanations; text not in brackets should go directly into the SCSI standard. [NOTE: Some unchanged parts of Table 7-66 were truncated. My printer doesn't have the smaller type that John's has.] [Change Table 7-66, on page 7-78, to:] Table 7-66: Control Mode Page ================================================================ Bit| 7 | 6 | 5 | 4 | 3 | 2 | 1 Byte | | | | | | | ================================================================ 0 | PS |Reserved| Page Code (0Ah) -----|---------------------------------------------------------- 1 | Page Length (06h) -----|---------------------------------------------------------- 2 | ATISM | Reserved -----|---------------------------------------------------------- 3 | Queue Algorithm Modifier | Reserved | QE -----|---------------------------------------------------------- 4 | EECA | Reserved | RAENP | UAA -----|---------------------------------------------------------- 5 | Reserved -----|---------------------------------------------------------- 6 | -----|--- Ready AEN Holdoff Period 7 | ================================================================ [Add the following paragraph to page 7-78, ahead of the paragraph describing the RLEC bit.] An Allow Target Initiated SDTR Message (ATISM) bit of one specifies that the target is allowed to initiate a Synchronous Data Transfer Request message exchange when it detects that the previous data transfer agreement may have become invalid. An ATISM bit of zero specifies that the target shall not initiate a Synchronous Data Transfer Request message exchange. The target shall use the rules in 5.6.21 to determine what transfer agreement to use until a message exchange is initiated by the initiator(s).