This message is from the T13 list server.
Jeff, I'm not sure I follow the need to specify the protocol. The assumption is we are passing through an ATA command to an ATA controller. As such, the "cumbersome (and unneeded) table or switch statement" has always gone with the ATA controller. Somebody has to perform the lookup to go from command type to the sequence type (data protocol), whether it be at the highest level, lowest level, or somewhere in between. As far as vendor unique commands...good question. ATA Controllers have to understand that the command being passed to them is vendor unique. Understanding the command is vendor unique, then the controller won't make any assumptions about subsequent packets. Basically it will wait until it receives signals or FISes back from the target before understanding what the data protocol might be or what the next step is. I believe this is true in all cases. Suffice to say, I don't believe the existing ATA controllers on the market require knowledge of each and every vendor unique command for each and every target on the market, yet they do still allow for vendor unique commands. To summarize, I don't see the need to specify a data protocol since there currently is no need to specify data protocol in a SATA Register FIS. Nate -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Stevens Sent: Thursday, August 12, 2004 1:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [t13] T10/04-262r0 This message is from the T13 list server. Jeff I think you were actually looking at T10/04-262r0... 1. I don't think this addresses queuing very well. In the scope I have excluded queing from the support. That does not mean that it can not be made to work... 2. I agree with you. However, I do not think the CDB can be separated from the transport. The transport has direction, transfer size, and other useful bits of information. I included the DMA bit because an ATA host need to know to use DMA or PIO to transfer the data. I have also included the DRQ block size for PIO transfers. I think that gives you all the information you need to do the transfer. That being said, if it would make things easier to use, I can remove the DMA bit in favor of a field that specs protocol. What do others think? ------------------------------------------------ Curtis E. Stevens 20511 Lake Forest Dr. #C 214-D Lake Forest, Ca. 92630 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: [EMAIL PROTECTED] -----Original Message----- From: Jeff Garzik [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 11, 2004 7:20 PM To: Curtis Stevens Cc: Sheffield, Robert L; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [t13] SAT: Reminder - Teleconference Thur 8/12 9:00 AM PDT Curtis Stevens wrote: > Just a heads up, I posted a proposal (04-260.PDF) for > documenting how a SCSI command maps to an ATA command. This is fantastic. A standard method of ATA passthru is the last piece of the puzzle, WRT SCSI<->ATA translation, that Linux needed. Thank you. One problem, which appears to be easily correctable: Any ATA passthru method must specify the command protocol: DMA-In, DMA-Out, TCQ DMA-In, TCQ DMA-Out, PIO-In, PIO-Out, PIO-In-Mult, etc. Rationale: 1) For standard ATA commands, a cumbersome (and unneeded) lookup table or C 'switch' statement is required to obtain the command protocol. 2) The low-level ATA driver has no idea how to execute a vendor-reserved ATA command without the command protocol. My suggestion is to used the 'Reserved' byte for this data field. The current Linux implementation of the "taskfile ioctl" (a.k.a. ATA passthru) includes the command protocol field. Jeff
