On Tue, Dec 16, 2003 at 10:15:32AM -0800, Jason Thorpe wrote:
> Folks...
> 
> Native SATA controllers present a fairly different model as compared to 
> standard ATA controllers.
> 
> The most glaring difference is the fact that the notion of "master" and 
> "slave" drives on a channel is really non-existent.  Sure, some SATA 
> controllers emulate that mode, but SATA only has one drive per port[*], 
> and so on some 4-port controllers, what we really see is 4 channels, 1 
> drive per channel.
> 
> [*] SATA-II supports port expansion.  In this case, you have one 
> channel which can have up to 15 drives.  One port multiplier is allowed 
> per root port, and that port multiplier can have up to 15 ports on it.  
> No nesting of port multipliers is allowed.
> 
> Another glaring difference, especially with some newer controllers, is 
> that the legacy ATA register set does not exist at all.  SATA basically 
> encapsulates access to those drive registers in a frame (called a FIS), 
> and I'm working with one controller right now where you build the FIS 
> in memory and then tell the controller to send it to the drive; there 
> are no ATA registers mapped into the CPU's address space at all.
> 
> I would like to see our ATA code adapted to handle this.  I think the 
> following "clean-up" changes are necessary, at least:
> 
> 	1. Move all of the ATA register access stuff into wdc-specific files.
> 	   ATA register values are still valid in native SATA (they're really
> 	   part of the ATA command set), but the actual access needs to be
> 	   fully abstracted out.

I had something like this in mind when I added ATAPI support (this is why 
there is a sys/dev/ata/ata.c at the first place), but as we didn't have 
real hardware at this time, I didn't bother with providing an abstraction
to access the registers values.

I guess we would need a specific ata_wdc.c for SATA ?

> 
> 	2. The "atabus" layer needs to be changed to support more than 2 
> 	drives
> 	   per channel.
> 
> 	3. The "pciide" layer probably should be changed to support more than
> 	   2 channels.

Both of these shouldn't be hard.

> 
> I will do some of this work, but I'm going to need help from someone 
> who really understands this code (HI MANUEL! :-).
> 
> We also need to look at both ATA and SATA command queueing (in SATA, 
> the ATA-style command queueing is referred to as "legacy", and the SATA 
> command queueing is referred to as "native").  At a glance, the wd 
> driver appears to support only one outstanding ata_bio.  This clearly 
> has to change :-)
> 
> Again, I will do some of this work, but I'm going to need help from 
> someone who really understands this code (HI MANUEL! :-) and also how 
> legacy command queueing works (err, HI MANUEL! :-)

Well, I'm not sure I know much about legacy command queueing, exept that
because of the work in imposes in the controller driver, and the limited
number of outstanding commands I'm not sure it's a real win. This is why it's
deep in my todo list and I didn't get around looking at this yet (I'm more
interested in hot-plug, for example :)

I'll be away from Paris in 2 days, for 2 week, but I'll try to check my email
daily, so feel free to ask questions.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--