Linus Torvalds wrote:
> 
> On Fri, 1 Jun 2007, Jeff Garzik wrote:
>> With these old PATA devices, device reset is "six of one, half-dozen of the
>> other."  Using SRST is the only way to kick some ATAPI devices into working:
>> http://suif.stanford.edu/~csapuntz/blackmagic.html#reset
> 
> Well, wouldn't it be a good thing to
>  1) if BUSY/DRQ is set even before you try the problem, obviously skip the 
>     two polite cases, and go to #4
>  2) try to just do an IDENTIFY 
>  3) if that doesn't work, do a HOST RESET and then try again
>  4) if that doesn't work, do the full SRST
> 
> (or some variation of the above).

Skipping reset means it doesn't get the device away from a state that 
the previous boot may have configured itself to... standard "I didn't do 
reset" problems you see with any hardware.  Transfer modes and 
removeable media status notification are the most notable that are left 
in a semi-random state, but there are many other minor feature bits that 
fall into this category as well.


> (Btw, the 150ms wait after reset is really nasty. A few of those, and 
> we're wasting seconds during bootup. Why the hell does it do that, when 
> the old driver - and the spec - said 2ms?)

Upon quick review, it appears it should be 110ms.  And actually the spec 
says 3ms.  But to answer your question anyway... :)

The basic libata probe came from the code procedure that is found in a 
lot of PC BIOSen, even (IMO) more exposure than Linux:  Hale Landis's 
ATADRVR.  See the attached code sample for the relevant procedure, or 
the entire driver source code (PC DOS-style) at 
http://www.ata-atapi.com/atadrvr.zip

Upon further review, it looks like the 110ms delay is only per-ATAPI 
command, not during reset, as the sub_atapi_delay() calls don't actually 
delay before the ATAPI signature has been detected.


> I thought the default in Fedora was to use the PATA driver first? If so, 

<grin>  (see davej's reply)

	Jeff