This message is from the T13 list server.
Pat, As per my earlier email, any emulation of the PIO method for DMA leaves you with a limitation of 64K bytes per SCSI command. Hale's proposed solution is even more hardware intensive. It also is not trivial - frequently the hardware has access to the number of bytes it has been programmed to transfer, not the number that it has transferred (i.e. think of a count down counter). Obviously hardware could be changed to make this work, but it is a hardware change. And note that the host hardware has to change as well (to pass on these values), which I think is unlikely. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 10:38 AM To: [EMAIL PROTECTED] Subject: Re: [t13] Proposal to 'fix' ATAPI DMA This message is from the T13 list server. I haven't yet seen the intro, but I can reply to the proposal. My proposal (November?) last year was: a) Flip a bit in the op xA1 IdentifyPacketDevice to say you are device that bothers to report the bus residue, even for Dma, not just for Pio. b) Report the bus residue in x1F5:1F4 ByteCount at BSY DRQ C/D I/O = 0 0 c i StatusIn time. Since then I've added c) c) Also report x1F3 SectorNumber = x80 to say the device copied data In. Report x1F3 SectorNumber = x00 to say the device copied data Out. In all the Atapi device silicon I know, this is a firmware change only, no silicon change required. Silicon that automagically reports Good status despite the Atapi Data Fifo being not empty would have to learn to check for that (rare) condition. x4402 Pat LaVarre [EMAIL PROTECTED] http://members.aol.com/plscsi/ >>> Hale Landis 04/15/02 11:09AM >>> This message is from the T13 list server. This proposal was at the end of my previous message but just so that it is not lost in your email in-box, here is just the proposal. Comments requested, especially from host adapter folks. Hale's proposal follows: Should Hale get a document number??? Pat wants a Byte Count for each DMA data burst just as we have Byte Count for each PIO DRQ data blocks. This BC must be transmitted from the device to the host at some point in each DMA data burst. On the host side these BC values must be added up and made available to the host software. Lets assume that we are adding this feature to U-DMA because it is the only DMA we really want people using in the future (SW DMA has been obsolete for years, and not supported by ATA hosts for years; MW DMA probably should be made obsolete sometime soon). OK? How about this? For U-DMA we define a scheme where the CRC is replaced by this BC value? Or do we need to define an entirely new DMA protocol (how about Enhanced Ultra DMA?) that has not only the CRC but the BC value? We need to find a way for the device to send the BC to the host and still allow the host to send the CRC to the device. Any ideas? *** Hale Landis *** www.ata-atapi.com ***
