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

[Robert Hancock <hancockr@shaw.ca>]

Alan Cox wrote:
>> 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
> 
> You don't. Basically it is controller dependant. Pretty much all the
> newer controllers support the 32bit PIO data cycles. Most PCI controllers
> it makes no speed difference but host bus controllers (especially
> PIIX/ICH) really benefit.
> 
>> 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..
> 
> It goes back before IDE into the depths of the original compaq spec. When
> you have a device wired basically directly to the ISA bus (original IDE)
> it mattered. I don't believe it is relevant to any of the PCI controllers.

I guess that bit doesn't really make any difference with remotely modern 
drives, then.. Could we make that ata_id_has_dword_io check always 
return true if ata_id_is_ata returns true and only check word 48 if not?

I saw Willy Tarreau's patch from February for this, I agree that we 
should likely use a separate data_xfer method for 32-bit transfer (or if 
enough controllers should support 32-bit, then just make it be the 
default and make a separate 16-bit only function for those that don't), 
rather than punting the decision to the user with hdparm.

You mentioned in the thread for Willy's patch that "some
controllers have quirky rules for 32bit xfers" - any details anywhere?