Re: Should be Acard ATP8620 2SATA / 1 IDE driver

Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[Jeff Garzik]

jameshsu wrote:
> Should be in TEXT/PLAIN mode. --- resend
> 
> ************************
> Hello,
> 
> This driver has nothing changed since last time submit.
> However recently we download 2.6.23.1 kernel and found Acard ATP8620 SATA
> driver is still not there.
> Resend this message to submit the same driver again.
> Please help Acard to build in this SATA driver with latest Linux kernel.
> If any reason not able to add in, please let us know.

We would be glad to help!

This driver is an ATA driver, which duplicates the existing SCSI<->ATA 
translation code we already have.  It also fails to work around the 
problems ("quirks") found in a large number of ATA devices.

As such, it would be preferred that this ATA hardware use the existing 
ATA driver API.

You can see example drivers for advanced controllers such a 
drivers/ata/ahci.c and drivers/ata/sata_sil24.c, which are both 
FIS-based controllers with full NCQ support, hotplug support, port 
multiplier support, and many others.

It is important in Linux that we do not duplicate effort by merging 
drivers that duplicate the existing SCSI<->ATA translation layer, or 
fail to use our existing ATA API.

Overall, we wish to avoid adding another ATA driver inside the SCSI 
layer, without using the existing ATA<->SCSI code.

Is your hardware documentation public?  I can help provide a sample 
driver for your hardware, or help guide your engineers in this effort.

Regards,

	Jeff, the Linux ATA maintainer

Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[jameshsu]

Hi Jeff,

".....Is your hardware documentation public?  I can help provide a sample
driver for your hardware, or help guide your engineers in this
effort........"
 =>>>>>  Product spec is under preparation, will be provided soon.
Right after doc public, please help us to provide a sample driver in your
eralier conveniance??
This way to ensure SATA driver of this hardware will be compliance with
Linux kernel requirement.
Thanks!

James Hsu
----- Original Message -----
From: Jeff Garzik
To: jameshsu
Cc: linux-scsi@vger.kernel.org ; 'David Miller' ; James Bottomley ; Matti
Aarnio ; tytso@us.ibm.com ; IDE/ATA development list ; Andrew Morton
Sent: Tuesday, October 30, 2007 6:24 PM
Subject: Re: Should be Acard ATP8620 2SATA / 1 IDE driver


jameshsu wrote:
> Should be in TEXT/PLAIN mode. --- resend
>
> ************************
> Hello,
>
> This driver has nothing changed since last time submit.
> However recently we download 2.6.23.1 kernel and found Acard ATP8620 SATA
> driver is still not there.
> Resend this message to submit the same driver again.
> Please help Acard to build in this SATA driver with latest Linux kernel.
> If any reason not able to add in, please let us know.

We would be glad to help!

This driver is an ATA driver, which duplicates the existing SCSI<->ATA
translation code we already have.  It also fails to work around the
problems ("quirks") found in a large number of ATA devices.

As such, it would be preferred that this ATA hardware use the existing
ATA driver API.

You can see example drivers for advanced controllers such a
drivers/ata/ahci.c and drivers/ata/sata_sil24.c, which are both
FIS-based controllers with full NCQ support, hotplug support, port
multiplier support, and many others.

It is important in Linux that we do not duplicate effort by merging
drivers that duplicate the existing SCSI<->ATA translation layer, or
fail to use our existing ATA API.

Overall, we wish to avoid adding another ATA driver inside the SCSI
layer, without using the existing ATA<->SCSI code.

Is your hardware documentation public?  I can help provide a sample
driver for your hardware, or help guide your engineers in this effort.

Regards,

Jeff, the Linux ATA maintainer

Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[Jeff Garzik]

On Tue, Nov 06, 2007 at 07:25:46PM +0800, jameshsu wrote:
> Hi Jeff,
> 
> Please help Acard to add this chip spec on the web site in your earlier
> conveniance.
> http://gkernel.sourceforge.net/specs/
> http://linux-ata.org/driver-status.html#open_chipsets

Updated, thanks much!


> By the way, once you complete the SATA sample driver , please inform us , so
> we could modify, test and submit in the near future.
> If any chip info still missing or need us to involve, please let me know.

I began working on a sample driver, but looking at your document, it
appears you are AHCI-compatible?

If so, we would prefer to modify drivers/ata/ahci.c to support your
hardware.  This already supports AHCI variants from Intel, NVIDIA, ATI,
VIA, JMicron and Marvell.

	Jeff

Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[Jeff Garzik]

On Wed, Nov 07, 2007 at 05:13:55PM -0500, Jeff Garzik wrote:
> On Tue, Nov 06, 2007 at 07:25:46PM +0800, jameshsu wrote:
> > Please help Acard to add this chip spec on the web site in your earlier
> > conveniance.
> > http://gkernel.sourceforge.net/specs/

BTW, I put the doc in 

	http://gkernel.sourceforge.net/specs/acard/

Regards,

	Jeff

Re:Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[jameshsu]

FYI
----- Original Message -----
From: LaurenceWu
To: jameshsu
Cc: Jason Wu ; DerweiChen (陳德威)
Sent: Thursday, November 08, 2007 4:34 PM
Subject: Re: Should be Acard ATP8620 2SATA / 1 IDE driver


Hi James,

We didn't study about ata/ahci.c, but it should be based on AHCI1.0 or 1.1
spec. That is, NO P.M. FIS base switching, but supports both non-NCQ and NCQ
protocols.

For NCQ or nonNCQ, 8620 is very AHCI-like, although not fully compatible,
programmer can easily modify standard ahci.c
for 8620. The main differences between 8620 and AHCI are :

1. PRD table format changed, (please compare AHCI 1.x section 4.2.3.3 and
8620 datasheet section 7.3), 'I' bit in 8620 is defined as 'EOT' and NO
PRDTL value are available in the
    Command List Structure.

2. For NCQ transfer, PxIS bit 3(SDBS) is changed. ATP8620 add the Reg_144h
to accumulate 32 Sactive bits in each SDB FIS.
    The Reg_144h is RWC and all its 32 bits are 'ORed'  to form the PxIS
bit3 and interrupt, if PxIE bit 3 enabled.


Yes.  Modifying the ata/ahci.c is OK to support atp8620.

Regards,
Laurence
----- Original Message -----
From: jameshsu
To: laurence@mail.acard.com
Cc: Jason Wu
Sent: Thursday, November 08, 2007 10:36 AM
Subject: Re: Should be Acard ATP8620 2SATA / 1 IDE driver


FYI

ata/ahci.c driver structure should support our 8620 AHCI-compatible
hardware, right?!
Any restriction and special condition we should inform them??
If no, I will tell them nothing.
Please advise! Thanks!

James
----- Original Message -----
From: Jeff Garzik
To: jameshsu
Cc: Andrew Morton ; IDE/ATA development list ; tytso@us.ibm.com ; Matti
Aarnio ; James Bottomley ; 'David Miller' ; Daniel Weng ; Jason Wu ;
laurence@mail.acard.com
Sent: Thursday, November 08, 2007 6:13 AM
Subject: Re: Should be Acard ATP8620 2SATA / 1 IDE driver


On Tue, Nov 06, 2007 at 07:25:46PM +0800, jameshsu wrote:
> Hi Jeff,
>
> Please help Acard to add this chip spec on the web site in your earlier
> conveniance.
> http://gkernel.sourceforge.net/specs/
> http://linux-ata.org/driver-status.html#open_chipsets

Updated, thanks much!


> By the way, once you complete the SATA sample driver , please inform us ,
so
> we could modify, test and submit in the near future.
> If any chip info still missing or need us to involve, please let me know.

I began working on a sample driver, but looking at your document, it
appears you are AHCI-compatible?

If so, we would prefer to modify drivers/ata/ahci.c to support your
hardware.  This already supports AHCI variants from Intel, NVIDIA, ATI,
VIA, JMicron and Marvell.

Jeff

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[Jeff Garzik]

On Thu, Nov 08, 2007 at 07:34:22PM +0800, jameshsu wrote:
> From: LaurenceWu

> We didn't study about ata/ahci.c, but it should be based on AHCI1.0 or 1.1
> spec. That is, NO P.M. FIS base switching, but supports both non-NCQ and NCQ
> protocols.
> 
> For NCQ or nonNCQ, 8620 is very AHCI-like, although not fully compatible,
> programmer can easily modify standard ahci.c
> for 8620. The main differences between 8620 and AHCI are :
> 
> 1. PRD table format changed, (please compare AHCI 1.x section 4.2.3.3 and
> 8620 datasheet section 7.3), 'I' bit in 8620 is defined as 'EOT' and NO
> PRDTL value are available in the
>     Command List Structure.
> 
> 2. For NCQ transfer, PxIS bit 3(SDBS) is changed. ATP8620 add the Reg_144h
> to accumulate 32 Sactive bits in each SDB FIS.
>     The Reg_144h is RWC and all its 32 bits are 'ORed'  to form the PxIS
> bit3 and interrupt, if PxIE bit 3 enabled.
> 
> Yes.  Modifying the ata/ahci.c is OK to support atp8620.

This is good information, thanks.

After studying the datasheet I also noted a couple differences:

1) Port Multiplier support appears different from standard AHCI.

2) This chip includes target mode support.  Very nice, well done!
I hope that standard AHCI eventually supports this nice feature!

	Jeff

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[Mark Lord]

Jeff Garzik wrote:
>..
> 2) This chip includes target mode support.  Very nice, well done!
> I hope that standard AHCI eventually supports this nice feature!
..

Speaking of which.  Do we have a strategy as to how to implement/support
the target side of target mode on controllers which can do it?

The Marvell chips also have a target mode feature, and I'd like to add
support for it soon-ish, but it's now clear how you would like it plumbed
into libata.

It's almost like a separate driver/subsystem, except that would be very silly.

???

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[Jeff Garzik]

On Thu, Nov 08, 2007 at 02:52:26PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >..
> >2) This chip includes target mode support.  Very nice, well done!
> >I hope that standard AHCI eventually supports this nice feature!
> ..
> 
> Speaking of which.  Do we have a strategy as to how to implement/support
> the target side of target mode on controllers which can do it?
> 
> The Marvell chips also have a target mode feature, and I'd like to add
> support for it soon-ish, but it's now clear how you would like it plumbed
> into libata.
> 
> It's almost like a separate driver/subsystem, except that would be very 
> silly.

I'm letting the SCSI folks do the heavy lifting, implementing SCSI
target mode -- an effort already quite well along.

We should be able to piggyback off of that work.

	Jeff

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[Mark Lord]

Jeff Garzik wrote:
> On Thu, Nov 08, 2007 at 02:52:26PM -0500, Mark Lord wrote:
>> Jeff Garzik wrote:
>>> ..
>>> 2) This chip includes target mode support.  Very nice, well done!
>>> I hope that standard AHCI eventually supports this nice feature!
>> ..
>>
>> Speaking of which.  Do we have a strategy as to how to implement/support
>> the target side of target mode on controllers which can do it?
>>
>> The Marvell chips also have a target mode feature, and I'd like to add
>> support for it soon-ish, but it's now clear how you would like it plumbed
>> into libata.
>>
>> It's almost like a separate driver/subsystem, except that would be very 
>> silly.
> 
> I'm letting the SCSI folks do the heavy lifting, implementing SCSI
> target mode -- an effort already quite well along.
> 
> We should be able to piggyback off of that work.
..

MMmm..  I wonder what the most common use case is for target mode?

Everybody I've dealt with thus far uses it as a high-speed local comms interface,
which would suggest that it might be done as a network interface (ethernet emulation).

But that would confusingly go across driver subsystems,
despite that this is how it actually is used.

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[Jeff Garzik]

On Thu, Nov 08, 2007 at 03:19:52PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >On Thu, Nov 08, 2007 at 02:52:26PM -0500, Mark Lord wrote:
> >>Jeff Garzik wrote:
> >>>..
> >>>2) This chip includes target mode support.  Very nice, well done!
> >>>I hope that standard AHCI eventually supports this nice feature!
> >>..
> >>
> >>Speaking of which.  Do we have a strategy as to how to implement/support
> >>the target side of target mode on controllers which can do it?
> >>
> >>The Marvell chips also have a target mode feature, and I'd like to add
> >>support for it soon-ish, but it's now clear how you would like it plumbed
> >>into libata.
> >>
> >>It's almost like a separate driver/subsystem, except that would be very 
> >>silly.
> >
> >I'm letting the SCSI folks do the heavy lifting, implementing SCSI
> >target mode -- an effort already quite well along.
> >
> >We should be able to piggyback off of that work.
> ..
> 
> MMmm..  I wonder what the most common use case is for target mode?
> 
> Everybody I've dealt with thus far uses it as a high-speed local comms 
> interface,
> which would suggest that it might be done as a network interface (ethernet 
> emulation).
> 
> But that would confusingly go across driver subsystems,
> despite that this is how it actually is used.

The low-level driver itself will just be a dumb DMA send/receive engine,
with submit/completion APIs highly similar to the existing ones.  Then
you can easily provide a network interface interface (not a typo) on top
of that.

The biggest use case I've seen is in the embedded space, where you
really are creating a SCSI (or ATA) target, that appears to the
initiator/client to be a real SCSI-or-ATA device.

There are certainly other uses:  networking, creating a cheap SATA bus
analyzer, creating a cheap SATA bridge, ...

My main goal is to ensure that the low-level driver is as simple as
possible, which permits upper layers to actually figure out what
purposes it shall use.

Modern SATA is just a DMA engine with PHY control anyway (just like
networking), so we really just need to be sure to abstract away
initiator-mode (aka host mode) specifics in drivers that support target
mode.

	Jeff

SATA Target mode & libata

[Mark Lord]

Jeff Garzik wrote:
> On Thu, Nov 08, 2007 at 03:19:52PM -0500, Mark Lord wrote:
..
>> MMmm..  I wonder what the most common use case is for target mode?
>>
>> Everybody I've dealt with thus far uses it as a high-speed local comms 
>> interface,
>> which would suggest that it might be done as a network interface (ethernet 
>> emulation).
>>
>> But that would confusingly go across driver subsystems,
>> despite that this is how it actually is used.
> 
> The low-level driver itself will just be a dumb DMA send/receive engine,
> with submit/completion APIs highly similar to the existing ones.  Then
> you can easily provide a network interface interface (not a typo) on top
> of that.
..

The obvious BIG difference is that in host mode, *we* initiate communcations,
whereas in target mode, it has to just sit there waiting for a host to say something.

That's a pretty big change from how libata operates today,
in just about every respect.

> The biggest use case I've seen is in the embedded space, where you
> really are creating a SCSI (or ATA) target, that appears to the
> initiator/client to be a real SCSI-or-ATA device.
> 
> There are certainly other uses:  networking, creating a cheap SATA bus
> analyzer, creating a cheap SATA bridge, ...
> 
> My main goal is to ensure that the low-level driver is as simple as
> possible, which permits upper layers to actually figure out what
> purposes it shall use.
> 
> Modern SATA is just a DMA engine with PHY control anyway (just like
> networking), so we really just need to be sure to abstract away
> initiator-mode (aka host mode) specifics in drivers that support target
> mode.

Re: SATA Target mode & libata

[Jeff Garzik]

On Thu, Nov 08, 2007 at 03:49:17PM -0500, Mark Lord wrote:
> Jeff Garzik wrote:
> >On Thu, Nov 08, 2007 at 03:19:52PM -0500, Mark Lord wrote:
> ..
> >>MMmm..  I wonder what the most common use case is for target mode?
> >>
> >>Everybody I've dealt with thus far uses it as a high-speed local comms 
> >>interface,
> >>which would suggest that it might be done as a network interface 
> >>(ethernet emulation).
> >>
> >>But that would confusingly go across driver subsystems,
> >>despite that this is how it actually is used.
> >
> >The low-level driver itself will just be a dumb DMA send/receive engine,
> >with submit/completion APIs highly similar to the existing ones.  Then
> >you can easily provide a network interface interface (not a typo) on top
> >of that.
> ..
> 
> The obvious BIG difference is that in host mode, *we* initiate 
> communcations,
> whereas in target mode, it has to just sit there waiting for a host to say 
> something.
> 
> That's a pretty big change from how libata operates today,
> in just about every respect.

Not at all -- both initiator and target modes have the exact same tasks:  
1) send stuff to hardware, 2) receive hardware responses.

On modern SAS/SATA hardware, you have both command and response queues.

On modern SATA hardware, you have command queue and a received FIS list,
which provides essentially the same services.

Thus SATA target mode will simply need a "here is data I just received
from the wire" hook, and the rest of the infrastructure already exists.

Target mode will re-use ->qc_issue, and need a new ata_receive_fis()
function for asynchronously received FIS's (H2D FIS, etc.)

	Jeff

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[jameshsu]

Jeff,

First, appreciate for taking few minutes to answer my short question:

1) How is the status of ACARD Linux SATA driver after spec studying??.
Any progress and any qustion/help needed from Acard, esp., AHCI support??
If you have draft open source(driver) now, do you mind to share with us!
Please advise! Thanks!

Best regards & happy holiday season!

James
----- Original Message -----
From: Jeff Garzik
To: jameshsu
Cc: Jason Wu ; LaurenceWu ; Andrew Morton ; IDE/ATA development list ;
tytso@us.ibm.com ; Matti Aarnio ; James Bottomley ; Daniel Weng
Sent: Friday, November 09, 2007 12:22 AM
Subject: Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007


On Thu, Nov 08, 2007 at 07:34:22PM +0800, jameshsu wrote:
> From: LaurenceWu

> We didn't study about ata/ahci.c, but it should be based on AHCI1.0 or 1.1
> spec. That is, NO P.M. FIS base switching, but supports both non-NCQ and
NCQ
> protocols.
>
> For NCQ or nonNCQ, 8620 is very AHCI-like, although not fully compatible,
> programmer can easily modify standard ahci.c
> for 8620. The main differences between 8620 and AHCI are :
>
> 1. PRD table format changed, (please compare AHCI 1.x section 4.2.3.3 and
> 8620 datasheet section 7.3), 'I' bit in 8620 is defined as 'EOT' and NO
> PRDTL value are available in the
>     Command List Structure.
>
> 2. For NCQ transfer, PxIS bit 3(SDBS) is changed. ATP8620 add the Reg_144h
> to accumulate 32 Sactive bits in each SDB FIS.
>     The Reg_144h is RWC and all its 32 bits are 'ORed'  to form the PxIS
> bit3 and interrupt, if PxIE bit 3 enabled.
>
> Yes.  Modifying the ata/ahci.c is OK to support atp8620.

This is good information, thanks.

After studying the datasheet I also noted a couple differences:

1) Port Multiplier support appears different from standard AHCI.

2) This chip includes target mode support.  Very nice, well done!
I hope that standard AHCI eventually supports this nice feature!

Jeff

[PATCH] Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[Jeff Garzik]

On Tue, Nov 06, 2007 at 07:25:46PM +0800, jameshsu wrote:
> By the way, once you complete the SATA sample driver , please inform us , so
> we could modify, test and submit in the near future.
> If any chip info still missing or need us to involve, please let me know.

Any chance the patch below works?

	Jeff


 drivers/ata/ahci.c |    5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index ed9b407..7a42b4e 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -553,6 +553,11 @@ static const struct pci_device_id ahci_pci_tbl[] = {
 	/* Marvell */
 	{ PCI_VDEVICE(MARVELL, 0x6145), board_ahci_mv },	/* 6145 */
 
+	/* Acard */
+	{ PCI_VDEVICE(ARTOP, 0x000D), board_ahci },
+	{ PCI_VDEVICE(ARTOP, 0x000E), board_ahci },
+	{ PCI_VDEVICE(ARTOP, 0x000F), board_ahci },
+
 	/* Generic, PCI class code for AHCI */
 	{ PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
 	  PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff, board_ahci },

Re: [PATCH] Re: Should be Acard ATP8620 2SATA / 1 IDE driver

[Jeff Garzik]

On Thu, Nov 08, 2007 at 07:28:38PM +0800, jameshsu wrote:
> Not really understand your patch listed below. 
> We do not provide ahci.c file to you, so we don't know where the patch came from(diff from where)?? 
> Who create this and how can we get ahci.c file?? Can you tell us??

The file is found in the latest kernel source code.  Go to

	http://www.kernel.org/

and download the latest "full" kernel version, 2.6.23:

	http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.bz2

and then to get the latest kernel, apply this patch:

	http://www.kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.24-rc2.bz2

Let me know if you need help unpacking and patching the kernel!

	Jeff

Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007

[jameshsu]

Jeff,

Do you know who has SATA sample driver w/ AHCI support for reference (esp., 
for Acard SATA chip)??
If possible, please advise in your earlier convenience ! Appreciate for your 
help!
James
----- Original Message ----- 
From: jameshsu
To: Jeff Garzik
Cc: James Bottomley ; Matti Aarnio ; tytso@us.ibm.com ; IDE/ATA development 
list ; Andrew Morton
Sent: Tuesday, November 27, 2007 6:18 PM
Subject: Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007


Jeff,

First, appreciate for taking few minutes to answer my short question:

1) How is the status of ACARD Linux SATA driver after spec studying??.
Any progress and any qustion/help needed from Acard, esp., AHCI support??
If you have draft open source(driver) now, do you mind to share with us!
Please advise! Thanks!

Best regards & happy holiday season!

James
----- Original Message -----
From: Jeff Garzik
To: jameshsu
Cc: Jason Wu ; LaurenceWu ; Andrew Morton ; IDE/ATA development list ;
tytso@us.ibm.com ; Matti Aarnio ; James Bottomley ; Daniel Weng
Sent: Friday, November 09, 2007 12:22 AM
Subject: Re: Acard ATP8620 2SATA / 1 IDE driver - AHCI.C Nov082007


On Thu, Nov 08, 2007 at 07:34:22PM +0800, jameshsu wrote:
> From: LaurenceWu

> We didn't study about ata/ahci.c, but it should be based on AHCI1.0 or 1.1
> spec. That is, NO P.M. FIS base switching, but supports both non-NCQ and
NCQ
> protocols.
>
> For NCQ or nonNCQ, 8620 is very AHCI-like, although not fully compatible,
> programmer can easily modify standard ahci.c
> for 8620. The main differences between 8620 and AHCI are :
>
> 1. PRD table format changed, (please compare AHCI 1.x section 4.2.3.3 and
> 8620 datasheet section 7.3), 'I' bit in 8620 is defined as 'EOT' and NO
> PRDTL value are available in the
>     Command List Structure.
>
> 2. For NCQ transfer, PxIS bit 3(SDBS) is changed. ATP8620 add the Reg_144h
> to accumulate 32 Sactive bits in each SDB FIS.
>     The Reg_144h is RWC and all its 32 bits are 'ORed'  to form the PxIS
> bit3 and interrupt, if PxIE bit 3 enabled.
>
> Yes.  Modifying the ata/ahci.c is OK to support atp8620.

This is good information, thanks.

After studying the datasheet I also noted a couple differences:

1) Port Multiplier support appears different from standard AHCI.

2) This chip includes target mode support.  Very nice, well done!
I hope that standard AHCI eventually supports this nice feature!

Jeff