|
Home > Archive > Data Storage > October 2004 > UDMA - Need to read status register after command?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
UDMA - Need to read status register after command?
|
|
|
| Hi,
I'm designing an embedded ATA controller that supports UDMA operation.
I've found something in the T13 specs that is causing headaches. They seem
to require that the host read the status register after issuing a "Read
DMA" or "Write DMA" command. Furthermore, it seems to suggest that the
host wait until [(BSY=1 & DRQ=0 & DMARQ=1) or (BSY=0 & DRQ=1 & DMARQ=1)]
before proceeding to the data transfer phase. It seems to me that the host
should just send the command wait for either DMARQ=1 (and start
transferring data) or INTRQ=1 (error, send IRQ to the CPU to handle it).
In that case there is no need to read or poll on the status register. Or
maybe it's better to read the Status register once after the command is
sent to make sure that the ERR bit isn't set. But this business of waiting
for the status bits _and_ the DMARQ doesn't seem consistent with the goal
of pushing the ATA driver off the CPU. Can anyone help?
TIA,
Matt
| |
| Mark A. Odell 2004-10-08, 7:45 am |
| MattH <NOSPAMYhensonator@yahoo.com> wrote in
news:1097178440.FnMEz7F5KJZ7IyGDsvYnZg@1usenet:
> Hi,
> I'm designing an embedded ATA controller that supports UDMA operation.
> I've found something in the T13 specs that is causing headaches. They
> seem to require that the host read the status register after issuing a
> "Read DMA" or "Write DMA" command.
Of course, but not until the drive asserts INTRQ#. Once you issue the UDMA
command the disk signals change meaning and you can no longer read the
status register (you'll just get the LSB of the data). BTW, what rev. of
the ATA spec are you reading and what page(s)? I don't recall seeing such
a statement in either ATA-5 or 6.
> Furthermore, it seems to suggest
> that the host wait until [(BSY=1 & DRQ=0 & DMARQ=1) or (BSY=0 & DRQ=1 &
> DMARQ=1)] before proceeding to the data transfer phase. It seems to me
> that the host should just send the command wait for either DMARQ=1 (and
> start transferring data) or INTRQ=1 (error, send IRQ to the CPU to
> handle it).
Correct, you cannot poll the BSY or DRQ bits after issuing the UDMA
command. You're DMA state machine should begin watching the DMA handshake
signals to determine when data is ready. Of course, INTRQ# should also be
monitored.
> In that case there is no need to read or poll on the status
> register. Or maybe it's better to read the Status register once after
> the command is sent to make sure that the ERR bit isn't set.
You can't and you don't need to. If the ERR bit is set you'll get the
INTRQ# assertion.
> But this
> business of waiting for the status bits _and_ the DMARQ doesn't seem
> consistent with the goal of pushing the ATA driver off the CPU. Can
> anyone help?
Reading the status after the command issue is only for PIO commands. You
do need to read the status register *before* issuing the UDMA command to
ensure that you have the pre-requisites satisfied, that is, !BSY and DRDY
(ERR may also be set if the last command errored out). So, before a
command issue you should see pDisk->status = 0x50 or 0x51, then issue the
command and wait for INTRQ#. The DMA statemachine must deal with the UDMA
protocol in between.
HTH.
--
- Mark ->
--
|
|
|
|
|