This message is from the T13 list server.
> > ... I'm more confident in algebra than in English ...
> > If [D = H] ... "has to be" ... what makes it so?
> "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/02/02 05:49PM
> all of your examples have been DATA IN, not DATA OUT.
Thanks for explaining here how I failed to hear what you heard: tellingly, this is not
MY memory of this confused conversation. I wonder how little of what I rehearsed in
thought I did then post? Below at the next occurrence of the seven char string
"UDmaOut" I (re?)post a Data OUT example.
> Harlan Andrews <[EMAIL PROTECTED]> 01/02/02 03:43PM
> What are you talking about?
Thank you likewise for you continued interest, and your help in making my concerns
here less muddy. I'll try now to restate my question in short. Then I will follow
with the two most clearly helpful AtapiDmaIn and AtapiDmaOut examples people here have
helped me remember ...
> What are you talking about?
I'm trying to make it harder for an app to discover when (and thus to choke if) a host
& my new device negotiate an AtapiDma transfer where old hosts and old devices always
arranged for an AtapiPio transfers to occur.
I've concluded I need help from the host.
By "the host" I agree with Hale: I mean the OS for a direct-attached Atapi device, the
bridge for an Atapi device connected via a Usb/Atapi bridge, and so on.
I'd very much like to be told I'm wrong. Otherwise I'd like to see us all extend the
Atapi standard to let Atapi devices invite Atapi aware hosts to help. Then we could
fix this once in the OS/ bridge/ whatever, rather than repeatedly in every app.
> SwDmaIn/ UDmaIn
Specifically, I'm having trouble designing an AtapiDma device to cooperate with the
host to reproduce precisely the legacy AtapiPio byte counts.
One byte count that matters is the count of bytes written or read that the OS reports
to the app.
Another byte count that matters is the count of bytes actually written or read.
> Perhaps you could give an example ...
Suppose we try:
iocb x 12 0 0 0 FF 0 /i x1000
In English, this means the app sent the Cdb x 12 0 0 0 FF 0 (Inquiry For Up To xFF
Bytes) and the app asked the OS to move up to 4KiB of data bytes In.
Now suppose the device under test makes x91 bytes of Inquiry data available. With an
AtapiPio device we see the host copies in x91 bytes. With an AtapiDma device we see
the host copies in x92 bytes.
Whoops.
We're left hoping that that x92'nd byte of memory was pinned, allocated, and never
will be fetched to branch on. And we hope the app doesn't care about precision in the
count of bytes moved that the OS reports.
> UDmaOut
In simulation, me, I also see that bridging to Atapi UDma OUT moves as many as 2 * X +
1 extra bytes out, where X is the burst "word" length indeterminacy built into Ide
Udma protocols that rises with burst rate.
> Perhaps you could give an example ...
Suppose we try a WriteBuffer of x1FD bytes from a x1000 byte buffer:
iocb x 3B:02 00:00:00:00 0 01:FD 0 /o x1000
With an AtapiPio device, I see precisely x1FD bytes moved out.
With an AtapiUDma33 device I see x1FE, x200, or x202 bytes move, randomly by how the
buffering/timing worked out in the bridge. With hosts that pause for a turnaround
delay at x200 byte boundaries, I most commonly see x200 bytes move. Never do I see
x1FD bytes move.
Whoops.
Again, we're left hoping those x202 bytes of memory were all pinned and allocated, no
matter that the legacy only tells us x1FD bytes of memory were ok. And again we hope
the app doesn't care about precision in the count of bytes moved that the OS reports.
Me, in my own app code, I align the i/o buffer in virtual space and I include one
extra physical page on the end, which covers the long history of pain I've had with
byte counts being imprecise.
For me, how much imprecision to disregard in byte counts is a configuration parameter,
often zero for block transfers and something less persnickety for plug 'n play
transactions.
> UDmaIn
In simulation, the imprecision in byte counts is fully symmetric: the device can ask
to move X * 2 + 1 more bytes than the host expects.
Jim argued forcefully that such a device is broken, I agree.
If you asked, I'd argue that a host should cope: it should report that the device is
broken. But I don't mind leaving that "should" out of the standard at least until we
can agree on what goes wrong when neither the host or the device is broken.
> MwDmaIn/ MwDmaOut
I'm told the MwDma standard as written neglects to require the device to turnaround
DMARQ quickly enough to avoid the host thinking it wants to move another two bytes
than it does.
But I also hear in practice this isn't much of an issue. People found this was enough
of a problem that they taught their devices to turnaround DMARQ quickly. Accordingly,
I don't mind leaving MwDma out of the discussion until we can agree exactly how
imprecise UDma is.
> ...
I am any clearer than mud, yet? Happy new year?
Thanks in advance, hope this helps. Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
