This message is from the T13 list server.
Jeff My point is that the information is available to the bridge when the CDB is received. I do not think we want to get into specifying the intervening layers, there are many possible models. Software-wise, there is no difference between PIO multiple and PIO. In both cases the ATA host needs the DRQ block size. This will tell him how many blocks/interrupt to transfer. I also do not believe the transport can be separated from the CDB because this has the transfer length in addition to the direction. While I could place the protocol field in the CDB, there is no room for the length. The ATA host also needs this information to properly complete a PIO transfer. For DMA transfers, this information may also be necessary for buffer size allocation, although some implementations could do it without buffers. The reason I included the goals is that, given the applications I stated, queuing is not required. I am a member of the drive product team and understand the limitations. However, support of queuing would require asynchronous status notification by the bridge to the application. I don't think we really need to go there at this time. If this pass-through becomes wildly successful and starts to be used in a performance environment, then we can upgrade it to provide more capability. It is not the intention of this proposal to support ATAPI. More information would be required... The DMA vs PIO and DRQ size are provided by the client application. This information in combination with a direction bit, also provided by the client, gives you the available protocols. ------------------------------------------------ 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: Thursday, August 12, 2004 2:55 PM To: Curtis Stevens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [t13] T10/04-262r0 Curtis Stevens wrote: > 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? Fundamentally, the command protocol is tied to the command opcode being executed, not the transport. The transport merely implements the command protocol. This fact has remained true from the oldest PATA controllers to the newest SATA controllers (ones not yet on the market). Without an explicit command protocol field, the following information is missing: PIO versus PIO-Mult versus ATAPI PIO DMA versus TCQ DMA versus NCQ DMA versus ATAPI DMA A single byte, command protocol, can provide all this information and more. With command protocol byte, your CDB is "future proof": you don't need to specify additional bit flags for DMA, PIO Mult, TCQ, NCQ, etc. A command protocol byte automatically takes queueing into account. [personal note: any design that doesn't take TCQ/NCQ into account is, IMO, automatically outdated. Ask your drive guys ;-)] In the implementation of the low-level driver, all this information is required, and all this information is independent of transport. For known ATA commands, this missing information can be provided by a lookup table. For unknown (vendor reserved) commands, this information must be specified by the client app _somewhere_, since the low-level driver cannot know it. Jeff
