This message is from the T13 list server.
I have been a little troubled by the idea of making accommodations for vendor unique commands to the proposed standard ATA pass-through mechanism. Specifically, I want to avoid forcing the user (driver) of SATL from having to worry about determining protocol type. Consider a situation where a customer wants to use the pass-through mechanism for performing normal reads and writes (a.k.a. fast path operation). It slows down their implementation to have to parse and specify data protocol each time. I spoke with Bob Sheffield and he indicated a potential alternative that warrants consideration in my mind. Consider creating an ATA pass-through mechanism for standard commands and a separate ATA pass-through for vendor unique commands. Other comments follow: Extend field - Does it make sense to simply follow the SATA mechanism which always transfers a packet that includes all registers (including extended). Doing so maps well to SATA and removes the need for the "Extend" bit and 2 separate tables. This would also remove the need for the SRST field as well since there would be a control register containing the SRST bit. Multiple.Count field - Is this field really necessary? Isn't the host/driver supposed to configure this prior to issuing any PIO requests? As such, is it wrong to have the host/driver and SATL remember the value? In SATA, the target specifies the amount to be transferred for each PIO segment by setting it in the PIO Setup FIS. *.En, DMA fields - Are these bits required for vendor unique commands? I'm trying to determine the need for these fields when performing standard pass-through of well defined standard ATA commands. For standard defined ATA commands each field has a well-defined set of values or is not applicable. For the not applicable case the device will worry about whether the field has a relevant value in it or not. Thanks, Nate -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curtis Stevens Sent: Monday, August 16, 2004 10:37 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [t13] T10/04-262r1 This message is from the T13 list server. Jeff You make some really good points... 1. I have not really built in the ability to change PIO/DMA modes using standard set features. I will include a warning... 2. You generally have to follow the rules. I have provided protocol #0 as an out just for that reason. However, I can put in a warning to make it more clear. 3. I chose the list of protocols because I do not need to define them here. The list is taken directly from ATA/ATAPI-7. The developer of the translator has an abundance of documentation on the protocols listed. I do not think there is anyway to future proof this. 4. I will add vendor specific commands to this list. However, WD uses log pages for transporting vendor specific commands. Ergo, this is not a limitation for WD drives. 5. I agree that DMA and UDMA are virtually the same. 6. I am including the DMA bit because some very simple devices will not implement the protocol field. DMA, Direction, and Length really give you all the information you need for the vast majority of commands and makes for smaller implementation in some environments. ------------------------------------------------ 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Garzik Sent: Friday, August 13, 2004 6:26 PM To: Curtis Stevens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [t13] T10/04-262r1 * From the T10 Reflector ([EMAIL PROTECTED]), posted by: * Jeff Garzik <[EMAIL PROTECTED]> * Doc 04-262r1 gets my vote of approval. Major comments: * when a SET FEATURES - XFER MODE command is issued, any bridge / OS driver is -STRONGLY ADVISED- to perform implementation-specific actions necessary to accomodate the command [such as reprogramming controller PIO or DMA timings] * perhaps mention somewhere that command protocol, if specified MUST [using RFC language] be correct with regards to the command opcode. i.e. it should be a spec violation for the application to specify a READ DMA opcode but a PIO-In protocol. Behavior in that case is defined as undefined :) Minor comments: * I prefer my list of command protocols, because the list is more abstract and transport-independent. More "future-proof." * similarly, if one to pursue the idea of abstraction, it would be nice to have three bits: host-reset, bus-reset, and device-reset. rather than HWRST. * (regarding command protocol) "Bridges that do not implement this field may not be able to execute queued commands." I would add mention of similar limitation in execution of vendor-reserved commands * why separate protocols for pio-{in,out} and udma-{in,out} when you have a separate bit for data direction? * in practice DMA in/out and udma in/out are the same * is the DMA bit needed any longer? * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to [EMAIL PROTECTED]
