This message is from the T13 list server.
> "Mark Sawyer" <[EMAIL PROTECTED]> 01/25/02 11:56AM ... > In my case, the simplest solution, > in my not so humble opinion, > would be for the upper host layer > to pass the anticipated bytecount > to the lower layer. > Will they? I don't think it likely. Why? I'd rather not go there ;-( Ah, fun. As many saw here, I spent much time over Christmas demonstrating I could not say this better myself. I'd say this is exactly the trouble I'm facing. But I'm not yet clear if any fix short of having the host pass the anticipated bytecount would help you? The open and generic x 08 XX 50 UsbMass protocol differs from the less open solutions that preceded it precisely in this way: there the Cdb crosses the bus together with an anticipated bytecount and direction of data to move. Given an anticipated bytecount known to me as host, then I think the practical fix is to teach the AtapiDma devices to learn to report the residue, the count of bytes not willingly requested, now that AtapiDma is faster than AtapiPio. I think I remember Jim once mentioned this fix would be closely analogous to the Scsi IgnoreWideResidue messages. With a quasi-public feature like this defined, Atapi devices can compete according to how perfectly they solve this problem. Any device needing to connect via AtapiDma rather than via AtapiPio, but not offering the feature of accurate residue reporting, will in general work less well than the ad hoc heuristics put in place to guess what such a device would report if only it bothered to do so. Meanwhile, host folk can compete on how much blood, sweat, and tears they pour into building their ad hoc heuristics for coping with the less polite devices. Pat LaVarre >>> "Mark Sawyer" <[EMAIL PROTECTED]> 01/25/02 11:56AM >>> This message is from the T13 list server. Hello, t13: I want to thank everyone for their responses and I apologize for reopening the "DMA bytecount" can of worms. I have been following the DMA bytecount discussion with some interest now for several weeks. Hale said (Friday, January 25, 2002 10:44): >For any given SCSI CDB passed to an ATAPI device both the host >and the device know the exact or maximum number of bytes that >will be transferred assuming there is no error. I will grant you that the host [should know] and the device [certainly knows] the [exact] number of bytes that will be transferred [assuming there is no error]. That said, I am working at the device driver level, a lower layer sufficiently removed from the upper "host" layer such that I am not privy to the details of the underlying device filesystem or media format. Also, in my particular situation, the "host" layer does not request I/O transfers in bytes, it requests them in "blocks" ... hence my dilemma. Therefore, in order to ascertain the correct bytecount for DMA, I would have to do things which are, in my opinion, beyond the normal responsibility of a hardware device driver. Such as, interogate each packet sent to a device in order to devine what the current I/O transaction is all about, or interrogate the media structure (e.g. TOC) to ascertain the data format for each track, etc. etc. etc. And, as Hale pointed out in an earlier email, mixed mode CD's are problematic in that the type of data and hence the blocksize is different from track to track. In my case, the simplest solution, in my not so humble opinion, would be for the upper host layer to pass the anticipated bytecount to the lower layer. Will they? I don't think it likely. Why? I'd rather not go there ;-( Thanks, /mbs --- Mark Sawyer Sawyer Software Solutions, LLC 2 Lincoln Drive, Bow, NH 03304-3209 Tel: 603-228-9214 / Cell: 603-496-3509 / FAX: 603-228-4810 --- AOL's AIM: FirmwareWizard -----Original Message----- From: Hale Landis [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 10:44 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [t13] Question: ATAPI (CDROM) sector size for DMA >On Thu, 24 Jan 2002 17:59:06 -0700, Pat LaVarre wrote: >This message is from the T13 list server. >But some of us think in the lab we see the byte counts for UDma >Out gets off by more and more as the UDma burst rate increases. Pat, I really don't want to get started on this again but just so Mark doesn't get confused... For any given SCSI CDB passed to an ATAPI device both the host and the device know the exact or maximum number of bytes that will be transferred assuming there is no error. For "write" commands the number is exact... the host must be programmed in PIO mode or DMA mode to transfer exactly that number of bytes to the device. There is nothing vague about this, no random side effects, no lost data bytes, no extra data bytes (except maybe a pad byte as the last byte of the data transfer). For "read" commands, the story is a little more complex only because there are some "read" commands that can transfer a variable amount of data. These are commands like Request Sense and Inquiry maybe even Mode Sense. Just use PIO for these commands. But here even in PIO mode the host needs to be prepared to accept the maximum number of bytes the command can transfer. And again this maximun number is based on the CDB data, for example, it could be the Allocation Length value in the Request Sense CDB. Except for a few tape devices that really have variable block sizes, ALL commands that transfer data from the device's media have an exact block size that is know to both host and device BEFORE the command is executed... for any given command that transfers data from a device's media the host will receive exactly that number of bytes (except maybe a pad byte as the last byte of the data transfer)... In both PIO mode and DMA mode the host must be prepared to receive this amount of data otherwise you have a "hung device" problem that requries a reset to fix. Pat, I still don't understand where/what the problem(s) is(are) with ATAPI DMA operations. Yes, in any given Ultra DMA data burst the receiver of the data might receive a few extra bytes of data at the end of the burst but that is valid data... it is not extra data, it is not pad data, it is not a side effect... this data is just part of the total data transfer for the entire command. At the end of the last Ultra DMA data burst for the command there is no extra data, other than maybe a pad byte. This is because the sender of the data (host or device) knows how much data the current command transfers and the receiver of the data is expecting that amount of data (or in the case of commands like Request Sense, no more than some maximum amount of data). Where's the beef? (Sorry I just couldn't help myself.) *** Hale Landis *** www.ata-atapi.com *** _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
