[LinuxBIOS] filo ide speedup patch!

[Peter Stuge]

On Fri, Apr 06, 2007 at 03:16:41PM -0400, Tom Sylla wrote:
> A couple of comments on all of this:

Thanks for the comments!


> > After having processed the read command, it seems the hard disk
> > reports "not busy" before "there is data" but that's the wrong order
> > according to the ATA-3 working draft that I'm using for reference.
> > (From 1997 but it's the latest I've found available at no cost. T13
> > d2008r7b)
> 
> All of the ATA drafts, up to and inluding ATA-8 are available for
> free download from t13.org, as they have been for several years.
> ATA-3 has actually been withdrawn. ATA-5 and ATA-6 are usually the
> best references, they are the most easily readable.

Thanks for the notice! I didn't find the drafts there last time but
got them now.


> ATA-7 and ATA-8 include SATA, which starts to convolute them.

Right. I've also seen some mentions of PATA/SATA translation and
the effects, if any, it has on the PIO protocol.


> IDE UDMA is always going to be faster than PIO. If your intent is
> only to speed up CF, then it doesn't really matter, UDMA and MDMA
> CFs are still pretty rare.

The intent is to read up to 256 consecutive sectors from ATA devices
with one command rather than many commands reading one sector each.

This required changes in FILO and pio_data_in() is the central
function that we're debugging now.


> If you want to make all filo loads faster, you may want to look
> into IDE DMA.

Could be nice, but one step at a time. :)


> If you don't want to do that much work, you may want to at least
> try to use rep insd when you can. It is faster. All relatively
> modern IDE controllers support it just fine. (Some older
> controllers do not, however)

Would insd be less compatible than insw? I don't want to compromise
compatibility.

I see Hale Landis' ATA/ATAPI driver on ata-atapi.com also defaults to
16 bit transfers and he seems to have done pretty thorough research.


> In any IDE driver, polling "Status" is usually bad form. You should
> poll "Alternate Status", until BSY goes away, wait for the other
> bits to get set properly, then read Status once to clear the
> interrupt. Polling Status will sometimes lead to spurious
> interrupts, which *should* be innocuous, but sometimes can have
> confusing effects.

FILO doesn't use interrupts at all, so there should not be any
interrupt problems.

Anyway, thanks for making me go read ATA-6. It confirms what is in
the old ATA-3 draft.


Apparently there can be a delay in devices so that BSY is cleared
one PIO cycle before the other bits are valid, which makes no sense
to me, and is not allowed by either draft.

Reading altstatus would see BSY clear, then reading status would of
course still see BSY clear, but by then the other bits would also be
valid. If this is deliberate device design my head may explode.

Ward's SATA drive/controller reports BSY=0 DRQ=0 at first and BSY=0
DRQ=1 one PIO cycle later.


--8<-- ATA-3 draft Page 27
The device shall not change the state of the DRQ bit unless the BSY
bit is equal to one. When the last block of a PIO data in command has
been transferred by the host, then the DRQ bit is cleared without the
BSY bit being set.
-->8--

--8<-- ATA-6 draft Page 72
The BSY bit shall be cleared to zero by the device:
       1)   after setting DRQ to one to indicate the device is ready
to transfer data;
-->8--

I think the 50ms timeout should work and is the best we can do.


//Peter