Driver for sata adapter promise sata300 tx4

Driver for sata adapter promise sata300 tx4

[Otto Meier]

Hi,

This card use the sata chip pdc 40718 (as of my card)
the lastest sata_promise kernel with sata promise patch driver doesn't 
recognise
this card.

I added the following line to static struct pci_device_id 
pdc_ata_pci_tbl[]  in sata_promise.c:

        { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
          board_20319 },

and the card was recognised and seam to work without errors so far.

bilding a soft raid5 on it and moving data doesn't broke it.

It would be interesting to hear from the guru's if this is ok to do?.

Otto

Re: Driver for sata adapter promise sata300 tx4

[Daniel Drake]

Otto Meier wrote:
> This card use the sata chip pdc 40718 (as of my card)
> the lastest sata_promise kernel with sata promise patch driver doesn't 
> recognise
> this card.
> 
> I added the following line to static struct pci_device_id 
> pdc_ata_pci_tbl[]  in sata_promise.c:
> 
>        { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>          board_20319 },
> 
> and the card was recognised and seam to work without errors so far.

Yes, this should be fine (this is a 4-port SATA card right?)

Are you happy to produce and submit a patch yourself (read 
Documentation/SubmittingPatches) or should I submit one for you?

Thanks,
Daniel

Re: Driver for sata adapter promise sata300 tx4

[Otto Meier]

Daniel Drake wrote:
> Otto Meier wrote:
>> This card use the sata chip pdc 40718 (as of my card)
>> the lastest sata_promise kernel with sata promise patch driver 
>> doesn't recognise
>> this card.
>>
>> I added the following line to static struct pci_device_id 
>> pdc_ata_pci_tbl[] in sata_promise.c:
>>
>> { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>> board_20319 },
>>
>> and the card was recognised and seam to work without errors so far.
>
> Yes, this should be fine (this is a 4-port SATA card right?)
>
> Are you happy to produce and submit a patch yourself (read 
> Documentation/SubmittingPatches) or should I submit one for you?
>
> Thanks,
> Daniel
>
>
Yes you are right it is a 4-port sata-II 300 card (PDC40718 ). According to
the promise feature list it should support :

SATA300™ TX4 Highlights

    * Native Command Queuing (NCQ)
    * SATA Tagged Command Queuing (TCQ)
    * Large LBA support for drives above 137GB
    * Supports Serial ATAPI devices
    * Disk Activity LED Headers
    * Flexible future-proof upgrade for users with motherboards that
      only have a PCI interface


My question is also are these features (NCQ/TCQ) and the heigher 
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?

Here is the patch:

--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 
+0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_
board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },



Thanks
Otto

Re: Driver for sata adapter promise sata300 tx4

[Otto Meier]

Daniel Drake wrote:
> Otto Meier wrote:
>> This card use the sata chip pdc 40718 (as of my card)
>> the lastest sata_promise kernel with sata promise patch driver 
>> doesn't recognise
>> this card.
>>
>> I added the following line to static struct pci_device_id 
>> pdc_ata_pci_tbl[] in sata_promise.c:
>>
>> { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>> board_20319 },
>>
>> and the card was recognised and seam to work without errors so far.
>
> Yes, this should be fine (this is a 4-port SATA card right?)
>
> Are you happy to produce and submit a patch yourself (read 
> Documentation/SubmittingPatches) or should I submit one for you?
>
> Thanks,
> Daniel
>
>
Yes you are right it is a 4-port sata-II 300 card (PDC40718 ). According to
the promise feature list it should support :

SATA300™ TX4 Highlights

   * Native Command Queuing (NCQ)
   * SATA Tagged Command Queuing (TCQ)
   * Large LBA support for drives above 137GB
   * Supports Serial ATAPI devices
   * Disk Activity LED Headers
   * Flexible future-proof upgrade for users with motherboards that
     only have a PCI interface


My question is also are these features (NCQ/TCQ) and the heigher 
datarate be supported by this
modification? or is only the basic feature set of sata 150 TX4 supported?

Here is the patch:

--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },



Thanks
Otto


I just saw the patches of  Luke Kosewski regarding the SATA150 TX4 antipating
them it might be right to modify the patch to 


--- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 +0200
+++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200
@@ -183,6 +183,8 @@ static struct pci_device_id pdc_ata_pci_board_20319 },
{ PCI_VENDOR_ID_PROMISE, 0x3319, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 
board_20319 },
+ { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
+ board_40518 },
{ PCI_VENDOR_ID_PROMISE, 0x3d18, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
board_20319 },

bye 
Otto

Re: Driver for sata adapter promise sata300 tx4

[Daniel Drake]

Otto Meier wrote:
> My question is also are these features (NCQ/TCQ) and the heigher 
> datarate be supported by this
> modification? or is only the basic feature set of sata 150 TX4 supported?

NCQ support is under development. Search the archives for Jens Axboe's recent 
patches to support this. I don't know about TCQ.

> Here is the patch:
> 
> --- linux/drivers/scsi/sata_promise.c.orig 2005-08-01 17:09:48.474824778 
> +0200
> +++ linux/drivers/scsi/sata_promise.c 2005-07-31 12:57:06.415979512 +0200

Your patch will not apply because it is linewrapped. You also need to submit 
it in a mail of its own to the relevent lists and maintainer, with your 
sign-off  (see Documentation/SubmittingPatches)

> I just saw the patches of  Luke Kosewski regarding the SATA150 TX4 
> antipating
> them it might be right to modify the patch to
> 
> + { PCI_VENDOR_ID_PROMISE, 0x3d17, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + board_40518 },

It won't compile like this because board_40518 is not a valid identifier. I 
also think it doesn't really matter as it looks like these identifier codes 
have lost their numerical meanings, and now just signify:

board_2037x - 2 port SATA, maybe with an extra PATA port
board_20319 - 4 port SATA
board_20619 - 4 port PATA

Daniel

Re: Driver for sata adapter promise sata300 tx4

[Jens Axboe]

On Mon, Aug 01 2005, Daniel Drake wrote:
> Otto Meier wrote:
> >My question is also are these features (NCQ/TCQ) and the heigher 
> >datarate be supported by this
> >modification? or is only the basic feature set of sata 150 TX4 supported?
> 
> NCQ support is under development. Search the archives for Jens Axboe's 
> recent patches to support this. I don't know about TCQ.

It's done for ahci, because we have documentation. I have no intention
on working on NCQ for chipset where full documentation is not available.
But the bulk of the code is the libata core support, adding NCQ support
to a sata_* driver should now be fairly trivial (with docs).

-- 
Jens Axboe

Re: Driver for sata adapter promise sata300 tx4

[Jeff Garzik]

Jens Axboe wrote:
> On Mon, Aug 01 2005, Daniel Drake wrote:
> 
>>Otto Meier wrote:
>>
>>>My question is also are these features (NCQ/TCQ) and the heigher 
>>>datarate be supported by this
>>>modification? or is only the basic feature set of sata 150 TX4 supported?
>>
>>NCQ support is under development. Search the archives for Jens Axboe's 
>>recent patches to support this. I don't know about TCQ.
> 
> 
> It's done for ahci, because we have documentation. I have no intention
> on working on NCQ for chipset where full documentation is not available.
> But the bulk of the code is the libata core support, adding NCQ support
> to a sata_* driver should now be fairly trivial (with docs).


I have docs for the Promise NCQ stuff.  Once NCQ is fully fleshed out (I 
haven't wrapped my brain around it in a couple weeks), it shouldn't be 
difficult to add NCQ support to sata_promise.

	Jeff

Re: Driver for sata adapter promise sata300 tx4

[Jens Axboe]

On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Aug 01 2005, Daniel Drake wrote:
> >
> >>Otto Meier wrote:
> >>
> >>>My question is also are these features (NCQ/TCQ) and the heigher 
> >>>datarate be supported by this
> >>>modification? or is only the basic feature set of sata 150 TX4 supported?
> >>
> >>NCQ support is under development. Search the archives for Jens Axboe's 
> >>recent patches to support this. I don't know about TCQ.
> >
> >
> >It's done for ahci, because we have documentation. I have no intention
> >on working on NCQ for chipset where full documentation is not available.
> >But the bulk of the code is the libata core support, adding NCQ support
> >to a sata_* driver should now be fairly trivial (with docs).
> 
> 
> I have docs for the Promise NCQ stuff.  Once NCQ is fully fleshed out (I 
> haven't wrapped my brain around it in a couple weeks), it shouldn't be 
> difficult to add NCQ support to sata_promise.

Excellent!

-- 
Jens Axboe

Re: Driver for sata adapter promise sata300 tx4

[Otto Meier]

Jens Axboe wrote:
> On Mon, Aug 01 2005, Jeff Garzik wrote:
>   
>> Jens Axboe wrote:
>>     
>>> On Mon, Aug 01 2005, Daniel Drake wrote:
>>>
>>>       
>>>> Otto Meier wrote:
>>>>
>>>>         
>>>>> My question is also are these features (NCQ/TCQ) and the heigher 
>>>>> datarate be supported by this
>>>>> modification? or is only the basic feature set of sata 150 TX4 supported?
>>>>>           
>>>> NCQ support is under development. Search the archives for Jens Axboe's 
>>>> recent patches to support this. I don't know about TCQ.
>>>>         
>>> It's done for ahci, because we have documentation. I have no intention
>>> on working on NCQ for chipset where full documentation is not available.
>>> But the bulk of the code is the libata core support, adding NCQ support
>>> to a sata_* driver should now be fairly trivial (with docs).
>>>       
>> I have docs for the Promise NCQ stuff.  Once NCQ is fully fleshed out (I 
>> haven't wrapped my brain around it in a couple weeks), it shouldn't be 
>> difficult to add NCQ support to sata_promise.
>>     
>
> Excellent!
>
>   
Sounds great. If you have implemented NCQ  for sata_promise it would be 
nice if you
could forward me the patch, because i'm not  subscribed to the ML's

best regards
Otto Meier

Re: Driver for sata adapter promise sata300 tx4

[Jens Axboe]

On Mon, Aug 01 2005, Jens Axboe wrote:
> On Mon, Aug 01 2005, Daniel Drake wrote:
> > Otto Meier wrote:
> > >My question is also are these features (NCQ/TCQ) and the heigher 
> > >datarate be supported by this
> > >modification? or is only the basic feature set of sata 150 TX4 supported?
> > 
> > NCQ support is under development. Search the archives for Jens Axboe's 
> > recent patches to support this. I don't know about TCQ.
> 
> It's done for ahci, because we have documentation. I have no intention
> on working on NCQ for chipset where full documentation is not available.
> But the bulk of the code is the libata core support, adding NCQ support
> to a sata_* driver should now be fairly trivial (with docs).

Oh, and forget TCQ. It's a completely worthless technology inherited
from PATA, whos continued existence can only be explained by some
companies having invested money adding firmware support for it already
and/or because it sounds good to marketing who apparently rely on
customers thinking it must be similar to SCSI TCQ because it shares the
same name. In reality, they really share nothing. IDE TCQ makes a
mockery of the TLA, I hope the people that came up with it bury their
heads in shame for having wasted peoples time actually tring it out.

-- 
Jens Axboe

Re: Driver for sata adapter promise sata300 tx4

[Jeff Garzik]

Jens Axboe wrote:
> Oh, and forget TCQ. It's a completely worthless technology inherited
> from PATA,

Agreed.

There are a few controllers where we may -eventually- add TCQ support, 
controllers that do 100% of TCQ in hardware.  But that's so far down the 
priority list, it's below just about everything else.

There may just be little motivation to -ever- support TCQ, even when 
libata is the 'main' IDE driver, sometime in the future.

I give an outline of queueing stuff at

	http://linux.yyz.us/sata/software-status.html#tcq

Regards,

	Jeff

Re: Driver for sata adapter promise sata300 tx4

[Jens Axboe]

On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >Oh, and forget TCQ. It's a completely worthless technology inherited
> >from PATA,
> 
> Agreed.
> 
> There are a few controllers where we may -eventually- add TCQ support, 
> controllers that do 100% of TCQ in hardware.  But that's so far down the 
> priority list, it's below just about everything else.
> 
> There may just be little motivation to -ever- support TCQ, even when 
> libata is the 'main' IDE driver, sometime in the future.

Host supported TCQ only removes the pain from the software side, it
still doesn't make it a fast techology. The only reason you would want
to support that would be "it's easy, why not...". From my POV, I would
refuse to support it just from an ideological standpoint :-)

Legacy TCQ, hell no, not in a million years.

-- 
Jens Axboe

Re: Driver for sata adapter promise sata300 tx4

[Jeff Garzik]

Jens Axboe wrote:
> On Mon, Aug 01 2005, Jeff Garzik wrote:
> 
>>Jens Axboe wrote:
>>
>>>Oh, and forget TCQ. It's a completely worthless technology inherited
>>
>>>from PATA,
>>
>>Agreed.
>>
>>There are a few controllers where we may -eventually- add TCQ support, 
>>controllers that do 100% of TCQ in hardware.  But that's so far down the 
>>priority list, it's below just about everything else.
>>
>>There may just be little motivation to -ever- support TCQ, even when 
>>libata is the 'main' IDE driver, sometime in the future.
> 
> 
> Host supported TCQ only removes the pain from the software side, it
> still doesn't make it a fast techology. The only reason you would want
> to support that would be "it's easy, why not...". From my POV, I would
> refuse to support it just from an ideological standpoint :-)
> 
> Legacy TCQ, hell no, not in a million years.

This is largely a confusion of terminology.  On the SATA page,

"host-based TCQ" == host controller has a hardware queue (DMA ring, or 
whatnot)

"legacy TCQ" == making use of READ/WRITE DMA QUEUED commands.

I would only consider accepting the -intersection- of these two feature 
sets, where host TCQ and legacy TCQ are -both- present.  As an extremely 
low, low priority.  :)

As a terminology side note, the SATA community refers to "everything 
that is not NCQ" as "legacy TCQ".  Legacy TCQ doesn't necessarily imply 
use of the standard PCI IDE interface, handling SERV interrupts and all 
that nastiness.

Patches to software-status.html to make this more clear are certainly 
welcome, as well :)

	Jeff

Re: Driver for sata adapter promise sata300 tx4

[Jens Axboe]

On Mon, Aug 01 2005, Jeff Garzik wrote:
> Jens Axboe wrote:
> >On Mon, Aug 01 2005, Jeff Garzik wrote:
> >
> >>Jens Axboe wrote:
> >>
> >>>Oh, and forget TCQ. It's a completely worthless technology inherited
> >>
> >>>from PATA,
> >>
> >>Agreed.
> >>
> >>There are a few controllers where we may -eventually- add TCQ support, 
> >>controllers that do 100% of TCQ in hardware.  But that's so far down the 
> >>priority list, it's below just about everything else.
> >>
> >>There may just be little motivation to -ever- support TCQ, even when 
> >>libata is the 'main' IDE driver, sometime in the future.
> >
> >
> >Host supported TCQ only removes the pain from the software side, it
> >still doesn't make it a fast techology. The only reason you would want
> >to support that would be "it's easy, why not...". From my POV, I would
> >refuse to support it just from an ideological standpoint :-)
> >
> >Legacy TCQ, hell no, not in a million years.
> 
> This is largely a confusion of terminology.  On the SATA page,
> 
> "host-based TCQ" == host controller has a hardware queue (DMA ring, or 
> whatnot)
> 
> "legacy TCQ" == making use of READ/WRITE DMA QUEUED commands.
> 
> I would only consider accepting the -intersection- of these two feature 
> sets, where host TCQ and legacy TCQ are -both- present.  As an extremely 
> low, low priority.  :)

That's what I understand as host supported TCQ, you talk sanely with the
hardware and that handles the actual TCQ with the device. A controller
that just has a hardware queue but doesn't actually do queueing at the
device side is even less interesting, since it buys you very close to
nothing.

> As a terminology side note, the SATA community refers to "everything 
> that is not NCQ" as "legacy TCQ".  Legacy TCQ doesn't necessarily imply 
> use of the standard PCI IDE interface, handling SERV interrupts and all 
> that nastiness.

In part I agree with that, since "everything that is not NCQ" is legacy
in the way that if you have it, perhaps continue to support, but if not
don't bother since it's not worth it.

> Patches to software-status.html to make this more clear are certainly 
> welcome, as well :)

If I update that document, the wording will be stronger :-)

-- 
Jens Axboe