This message is from the T13 list server.
Jeff, My assertion is that there is no industry standard that prevents the PIO access while under DMA. Individual chip set vendors all have their own rules for handling things, but there is no industry consensus. My test is that if a customer came to me and asked me to defend my implementation, what would I do? I cannot reply that the other chip set venders that they could have selected all work with my device. That just loses me the business. If I could reply that "chip set vendor is not compliant with the ATA host adaptor standard FOO," then I have a chance (they will turn their wrath onto the chip set vendor). Until then, I have to assume that what is not forbidden is allowed, and accommodate it. Jim -----Original Message----- From: Wolford, Jeff [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 4:17 PM To: [EMAIL PROTECTED] Subject: RE: [t13] the Pio port accesses that occur during Dma This message is from the T13 list server. Jim, I do not agree with your statement at all that the hardware is responsible to terminate the current DMA. DEFINITION: It is only valid to access a device while the Host controller is in active DMA mode, not while the ATA bus is in active DMA mode (DREQ and DMACK active). Does EVERYONE agree with that statement ? It is determining this DREQ or DMACK (one or both being inactive) state that is difficult for software to figure out BEFORE it accesses the drive in PIO. VALID situation(s) to do a PIO in the middle of DMA cycles: 1) Drive errors, asserts IRQ, but the DMA data transfer has not been completed. 2) The DMA access is made up of ONE PRD table, but made up of several different LBA address ranges. If the host hardware stops the DMA for every PIO, it would never be able to support this mode (which is outlined in the old SFF-8038i spec). Under the first case, I agree the proper thing to be done is disable the BM active bit in the host controller BEFORE the PIO Under the second case, this requires a driver that was design to support this so it has a tougher case to figure out. As far as the ATA bus being inactive during these PIO cycles, these two examples have one thing going for them: There is a pending interrupt on the channel under both cases. Jeff Jeff Wolford Email: [EMAIL PROTECTED] Senior Storage Architect Storage Interface and Tools - PC Storage Group Voice: (281) 514-9465, Pager: (800) 973-5739 Compaq Computer Corporation > Actually you can do any PIO operation at the host level while > a DMA command > is active. It is the responsibility of the host hardware to > terminate the > current DMA burst, allow the PIO operation to be executed, and then to > resume the DMA command by initiating another UDMA burst. > Obviously if the > PIO operation has the effect of terminating the command in > progress, then > the DMA is not resumed. But normally this is not the case. > All of the DMA > operations are transparent to higher level software. > > Note this this is true for single word, multiple word, and > ultra DMA. As I > mentioned earlier, it's a primary reason why you can > terminate bursts and > initiate new ones during the execution of a DMA command. > > Jim > > > -----Original Message----- > From: Pat LaVarre [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 4:18 PM > To: [EMAIL PROTECTED] > Subject: [t13] the Pio port accesses that occur during Dma > > > This message is from the T13 list server. > > > > ... > > I wonder if hosts ever write x04 SRST to x3F6 DeviceControl > without first > terminating Dma? > > > > a device executing a DMA data transfer command > > should have status of BSY=1 until the command is completed. > > Is this required or only recommended by the Ansi texts? > > > > Pat, where do you see such ideas documented anyway? > > Documented??? > > To my knowledge, how Ata/pi hosts & devices actually do > mostly work isn't > written down with much precision - not at the bus analyser > level, as opposed > to the digital scope level. > > What I'm hearing here more specifically is that one easily observable > distinction among Usb/AtapiUDma bridges is how promptly the > bridge reports > Usb > bCSWStatus = x02 PhaseError when the host & the device do > disagree over > which > direction to copy data. > > I haven't yet heard specifically how the bridge folk accomplish this. > > I did hear people who don't think about the problem end up > hanging cleanly, > UDma sender and receiver each waiting forever for the other. > > I did hear some talk of fetching x1F2 & x03 I/O:C/D. > > > > Pat, where do you see such ideas documented anyway? > > I haven't seen the reality of the device & the host > disagreeing over which > way > to copy data acknowledge anywhere outside the Usb Mass > community. Quoting > from http://members.aol.com/plscsi/ftf.html I remember now > there the most > relevant diagram is: > > http://members.aol.com/plscsi/13cases.gif > originally closer to > http://members.aol.com/plscsi/20000125/13cases.gif > published as "Table 6.1 - Host/Device Data Transfer Matrix" > in the section > titled "6.7 The Thirteen Cases" of the 103,609 bytes of > http://www.usb.org/developers/data/devclass/usbmassbulk_10.pdf . > > > Curiously yours, > > x4402 Pat LaVarre [EMAIL PROTECTED] > http://members.aol.com/plscsi/ > > > >>> RE: RE: [t13] UDMA Bursts - Pause versus Termination > >>> Hale Landis 04/11/02 08:27AM >>> > ... > > On Wed, 10 Apr 2002 16:44:00 -0600, Pat LaVarre wrote: > >This message is from the T13 list server. > >I remember hearing some talk of teaching a host to read x1F2 > & x03 I/O C/D > >during a Dma data transfer to discover which way (In to the > host or Out > from > >the host) the device was trying to copy the data ... > > This makes no sense because a device executing a DMA data transfer > command should have status of BSY=1 until the command is completed. > There is no "interrupt reason" data to be read by the host until the > end of the command. Pat, where do you see such ideas documented > anyway? > ... >
