Subject: Re: Rework of ATA code to support native SATA controllers
To: Jason Thorpe <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 12/16/2003 22:34:06
On Tue, Dec 16, 2003 at 10:15:32AM -0800, Jason Thorpe wrote:
> 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
> 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 <firstname.lastname@example.org>
NetBSD: 24 ans d'experience feront toujours la difference