Re: Kernel Summit request for Discussion of future of ATA (libata) and IDE

[Robert Hancock <hancockr@shaw.ca>]

Alan Cox wrote:
>> * There are still corner case in libata core - PIO is dead slow
>> compared to drivers/ide/,
> 
> There are two there - libata keeps IRQs blocked for longer in PIO mode as
> well which is a factor for realtime that needs looking at, as well as
> using 16bit not 32bit I/O for most devices (which is trivial to fix). The
> IRQ masking stuff is more complex and old IDE handles it far better for
> PIO on non shared IRQ interfaces. That is actually probably the most
> complicated thing to address of the stuff you'd want to do if you were
> going to kill off old IDE.

I was looking into the 32-bit PIO issue a bit yesterday. It looks like 
some of the VLB libata drivers are doing this internally already, so it 
shouldn't be hard to do this in the core. Only question is how we know 
generically if the controller can do it or not? It looks like in old 
IDE, a few controllers explicitly disable it, but it appears that it 
doesn't default to on for any controller, so it's possible there are 
others on which it doesn't work. Presumably anything on an actual 16-bit 
bus (ISA, LPC, etc.) wouldn't like it, to start with.

There's also the matter of the identify bit to indicate whether the 
drive supports 32-bit transfers, which was reallocated to trusted 
computing in ATA-8 so any drive matching that standard will indicate not 
supported. I couldn't track down where that bit was actually defined in 
the first place, all the way back to ATA-1 it seems to be indicated as 
reserved. Actually, I'm not sure why the drive cares in the first place, 
it would seem like a pure host controller issue..