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--