[LinuxBIOS] filo ide speedup patch!

[Tom Sylla]

Peter Stuge wrote:
>> 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.

Well, maybe, but no more that doing multiple sector reads without 
checking if the drive can do them :) You really should be checking word 
47 of the IDENTIFY DEVICE data to know how many sectors per interrupt 
are transferred for READ/WRITE MULTIPLE. I didn't see that in your patch 
any where. In general, the various IDE speed-ups can only be done when 
the drive, the controller, and the chipset can do them. Sometimes, there 
is a defined way to detect if they are supported. The ID data is usually 
a good place to look first.

> 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.

I have worked with Hale on several occasions, while debugging and 
validating a couple of IDE controllers. I know his software pretty well. 
He supports 8, 16, and 32 bit transfers. 32-bit is in ATAIOPIO.c line 402:

          if ( pxw == 32 )
          {
             // do REP INSD
             pio_rep_indword( addrDataReg, bufSeg, bufOff, wc / 2L );
          }

We used ATACT and ATAMDT from Hale a lot, and always ran 32 bit mode. 
The default of 16 *is* probably to be safe, but you would have to have a 
pretty crusty IDE controller for it not to support 32-bit PIO.

You may want to try 32 bit mode, and see how much it speeds things up; 
if it isn't worth it, ignore me. If it is a reasonable gain, maybe make 
it a build option or whatever is equivalent for FILO. The 
"compatibility" depends on the southbridge, the FILO user could speed it 
up if they want.

> 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.

You will find all sorts of inconsistencies and non-spec-compliant IDE 
devices brand new. Any one trying to write another IDE driver encounters 
these sorts of things. :) SATA drives and controllers are notorious for 
doing poor PIO emulation.