This message is from the T13 list server.

What I find very interesting is the diverse perspectives that everyone
brings to the table, all strongly colored by the requirements of their
various implementations and their experiences with same ...

Jim said (Friday, January 25, 2002 20:53):
>With DMA the HOST DOES NOT NEED to know the amount of data to transfer
>before the device starts transferring data.

All I can say to that is "Maybe not in your world" ...

In my world, as a host-side driver developer, I am responsible for the DMA
in one of two ways:

 (1) I program some hardware, a DMA controller (a la 8237), to perform the
actual DMA.  This involves, among other things, programming the transfer
count.  All of the DMA controllers that I am familiar with require a
transfer count.

 (2) I implement a "soft-DMA" where I, (host-side embedded controller) am
responsible for emptying the FIFO as the data comes in.  This has been done
in both interrupt and polled implementations.

In the first instance, the transfer count is a hardware requirement.  It's
just that simple.

In the second instance (my most recent experience), not having knowledge of
the transfer count is also a problem.

In the case of DMA READ (from HOST perspective):  How much data do I suck
from the FIFO?  If data stops coming is the transfer complete or was the
transfer simply paused by the device?  How long do I wait before deciding
that the transfer is complete as opposed to simply paused while the device
went to fetch more data?  The state of DMA-REQ is not sufficient by itself.

In the case of "soft-DMA", my problem was further complicated in that the
I/O channel between the device and the host is not available for PIO during
a DMA transfer ... in other words, I can't safely interrogate status to
ascertain the state of BSY, DRQ, DRDY, IO, CD or anything else for that
matter that might tell me the state of the device.

Regards,

/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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Mcgrath, Jim
Sent: Friday, January 25, 2002 20:53
To: 'Pat LaVarre'; [EMAIL PROTECTED]
Subject: RE: [t13] just use Pio


This message is from the T13 list server.



With DMA the HOST DOES NOT NEED to know the amount of data to transfer
before the device starts transferring data.  In all cases the device can
halt the transfer of data when it runs out by terminating the DMA burst.
The device indicates that all of the data has been transferred for the
command by terminating the burst and asserting INTRQ.

If you want to use odd byte counts for a command then PIO still makes some
sense, but none of the sector sizes we've been discussing have that problem
(for read/write of user data).

Jim


-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 25, 2002 5:05 PM
To: [EMAIL PROTECTED]
Subject: [t13] just use Pio


This message is from the T13 list server.


> [EMAIL PROTECTED] 01/25/02 08:43AM
> Just use PIO ...

In passing I happened to notice Hale is here restating a part of Jan 1996
Sff8020i rev 2.6 paragraph 5.4 that I think I remember never made its way
into Ansi texts.

Long time listeners to this reflector surely will find the spectacle of Hale
& Sff agreeing something like as amusing as I do?

I quote:

"For some commands, such as Mode Sense, the Host does not know the amount of
data that will be transferred, and shall rely on the Byte Count supplied by
the Device to transfer the correct amount of data.

> Just use PIO ...

Wish I could, wish I could, wish I could, but Ansi Pio development stopped
cold way back at the 17e+6 byte/s of Pio4.

Pat LaVarre


Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to