This message is from the T13 list server.
> Subject: [t13] RE: countable data bytes > Subject: [t13] USB vs. ATA/ATAPI data xfer matrix > Subject: [t13] is ATAPI DMA broken? > ... to "call to order" the discussion I suggest ... Thanks, hi. > > I'm liking the one post per author per > > day limit for this topic. I skipped Sunday, so I can fit two posts in today! We've got troublesome jargon here - can we fix that? > 1) ... data transfer matrix ... broken host ... I prefer to say "unspecified" rather than "broken". In my last email I answered: "... in effect, we have said) the effect is unspecified when the host models the device inaccurately. But that neglect doesn't help us all interoperate." With this you can agree? I'm not sure we have left the thirteen cases Entirely unspecified. For instance, I remember hearing UDMA folk conclude that compliant UDMA reliably deadlocks if host & device disagree over which way to copy bytes. > 2) look at the information below. How about we try me echoing your argument in my own words? If you find you can agree with how I express your argument, then we will have progressed. Basically, in place of "broken" and "transfer" I'd like to say "unspecified" and "clock". I also introduce the troublesome word "copy", because what makes or breaks the system is how many bytes pass thru the system, not how rounded up that count has to be across one bus or another. I'm certain you don't mean by "transfer" what I mean by "copy". I think by "transfer" you mean what I express as "clock". I think the term "clock" implies less about what the host & device do with those "clock"ed words. I'm happy to adopt your language for the difference between what is "clocked" and what is "copied": that is the "pad". > Unless the device is broken it will transfer the > same number of bytes in both PIO or DMA Agreed, to focus our discussion, we will contrast only ATAPI PIO/ ATAPI DMA bus traces in which the host and the device chose to ask to copy In or Out the same number of bytes in response to the same Cdb. > transfer ... may include a pad byte Agreed, to copy Y bytes, we must clock across Z bytes across the bus, where Y <= Z. > transfer ... may include a pad byte as the last byte ... > If the actual transfer was an odd number of bytes > the last byte of the last word is a pad byte. Agreed, to copy Y bytes, when Y is odd, rounding up to 16-bit ATAPI requires that we clock across at least Z bytes, where Z = Y + 1. Agreed, T13 also tells us that the bytes we copy come first, the pad comes after. > PIO or DMA ... - the transfer is always an even > number of bytes. Agreed, ATAPI always clocks a count of "word"s across the bus, thus always an even count of bytes. > PIO.numberBlocks > has no relationship to DMA.numberBlocks Agreed, the count of INTRQ in PIO usually does and certainly may differ from the count of INTRQ in DMA. > if the command ends with no error then > PIO.wordsTransferred == DMA.wordsTransferred Agreed, the count of "word"s clocked across the bus will be the same, no matter PIO or DMA, whenever the host & device agree out of band how many "word"s to clock which way. > It doesn't matter if PIO or DMA is used - the last > byte (of the last word) might be a pad byte. Agreed, PIO or DMA can be used to clock across the bus any number of "word"s, and the host & the device can agree out of band to discard any of the bytes. > It doesn't matter if MultiWord DMA or UltraDMA is > used - the same N words are transferred. Agreed, PIO, SwDMA, MwDMA, UDMA are all equally capable of clocking N "word"s across the bus, 'whenever the host & device agree out of band how many "word"s to clock which way'. > Nothing in the typical host side controller or in > the ATA/ATAPI protocols know anything about odd > transfers or pad bytes. Not exactly. With ATAPI PIO, the typical host controller passes the x1F5:1F4 Cylinder = ByteCount of each DRQ INTRQ back to the host cpu. Any host that cares enough to bother to count bytes can notice when this count is odd. T13 spec echoes SFF in saying that only happens in the last DRQ INTRQ, some hosts permit this to happen more often. When this count is odd, the ATAPI PIO standard tells us there is precisely one pad byte, and it is the last byte. > PIO and DMA are the same in this respect - the > ATA/ATAPI hardware and protocols transfer only > 16-bit "words" of data. Agreed, PIO and DMA clock only whole "word"s across the bus. There is only one clock for all sixteen data bits. There is no way to clock less than a whole "word" across the bus. UDMA adds a CRC "word" every so often, but here we're not counting those. > (yea, I didn't use exactly the same notation). Pretty close. I see you kept the numbers 1 .. 13 for the cases that USB names more like: [1] Hn = Dn, [2] Hn < Di, [3] Hn < Do; [4] Dn < Hi, [5] Di < Hi, [6] Hi = Di, [7] Hi < Di, [8] Hi != Do; [9] Dn < Ho, [10] Ho != Di, [11] Do < Ho, [12] Ho = Do, [13] Ho < Do. I never got used to the case numbers myself, they came after. > ... Do I yet sound like I'm understanding anything you're saying? Curiously yours in redeemable(?) ignorance, Pat LaVarre
