Subject: Re: Rework of ATA code to support native SATA controllers
To: Manuel Bouyer <bouyer@antioche.eu.org>
From: Jason Thorpe <thorpej@wasabisystems.com>
List: tech-kern
Date: 12/16/2003 14:08:23
--Apple-Mail-3-963506596
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed
On Dec 16, 2003, at 1:34 PM, Manuel Bouyer wrote:
>> 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 ?
It will be different for every controller, since each controller's
interface is going to be different in this regard. Perhaps a library
routine that builds the initial command FIS would be useful, but that
remains to be seen.
I guess the analogy is more like the umass_isdata.c stuff, for that
USB->ATA dongle (I've never actually seen one of this, but I did run
across it while diving into the ATA code to figure out how to handle
this stuff).
I think part of the problem is that "atabus" is in wdc.c, when it
really should be in ata.c, and all of the low-level register frobbing
should be in ata_wdc.c (where most of it is, but clearly not all of
it).
>> 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.
Yah, I didn't think they would be.
> 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 :)
Yah, I'm also quite interested in hot-plug. The Silicon Image SATA
controllers support it, for example (not all SATA controllers support
it).
Native SATA command queueing has the potential of improving performance
a lot. One controller I'm working with now can issue up to 31 commands
per root port (i.e. those slots are shared if a port multiplier is
used, but still...)
> 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.
Ok, cool. Be sure that I'll have some :-) I'll be traveling during
Christmas, too, but I have VirtualPC for my laptop, so I'll be able to
test code as I hack on it.
-- Jason R. Thorpe <thorpej@wasabisystems.com>
--Apple-Mail-3-963506596
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/34JXOpVKkaBm8XkRAhpqAJ49zbvyJRDd1uo94+yPIBq7Ow+CTQCff1o/
lFtnFijy/6SaU48EPyWplkQ=
=N2HD
-----END PGP SIGNATURE-----
--Apple-Mail-3-963506596--