[LinuxBIOS] filo ide speedup patch!
Tom Sylla
tsylla at gmail.com
Sat Apr 7 00:07:58 CEST 2007
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.
More information about the coreboot
mailing list