This message is from the T13 list server.
I've asked Silicon Images to add a "why are we doing this" section to the e03132r2 proposal. To answer your question: In my mind, we're solving more than just a host-to-ATAPI direction problem, but rather the issue of a host-to-ATAPI "bridge" doesn't know the DMA data direction of any given ATAPI command. An ATAPI device better know the direction or it won't operate at all, but the bridge could use special handling. When we set the new direction bit it then knows what the direction is without snooping the command octet in the packet. Some folks don't mind sniffing, but others would rather control the complexity of this sort of bridge. Extra for everyone to gnaw on: Part of the proposal is to not break existing host drivers that won't set the direction bit. The only way to do this is by masking the existing DMA capabilities bits, and relocate them elsewhere. The issue I have with the current proposal is it doesn't take into account poorly written drivers that won't handle the new bits in the existing DMA register(s). Since we have no idea whether overlapped commands have sensitivity to this new direction bit, we should also mask the overlapped support flag. If you have something else you are trying to fix that is related to ATAPI direction determination, please, in a very succinct fashion, write up a solution you'd like to see in an official proposal and submit it to T13. What is not part of this proposal is counting data words, since from the bridge's perspective the transfer will continue in the indicated direction until either an interrupt from the device completes the transfer (error or not) or the host aborts the transfer due to a timeout (or whatever it's reason). I don't think "word" counting is an issue that we need to address to build minimal bridge support. The proposal is loose enough that a bridge that supports any existing ATAPI device will have more lifting to do than a device that integrates a bridge through the changing of the ATAPI identify data to meet this requirement. The integrated bridge can push this responsibility to the ATAPI device, whereas the stand-alone bridge must do it for the ATAPI device. TTFN, MKE. -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED] Sent: Thursday, November 20, 2003 12:41 PM To: Eschmann, Michael K Cc: [EMAIL PROTECTED] Subject: RE: [t13] e03132r2 DMADIR bit for PACKET command > Looking forward to the flurry of emails this will generate. Regards, MKE. How lazy can I be? Can anyone easily tell me which issues we're solving? Just the host and the device disagreeing over which way a CDB says to copy data ... or more than that? Pat LaVarre
