lkml.org 
[lkml]   [2008]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel Summit request for Discussion of future of ATA (libata) and IDE
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..


\
 
 \ /
  Last update: 2008-08-04 22:09    [W:1.813 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site