linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* VIA Serial ATA chipset
@ 2003-08-11  2:17 Misha Nasledov
       [not found] ` <20030811055522.31F6427A21@mail.medav.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Misha Nasledov @ 2003-08-11  2:17 UTC (permalink / raw)
  To: linux-kernel

Hi,

I am wondering if the VIA Serial ATA chipset found with the VIA KT600
chipset is yet supported. An lspci -v reveals:

00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device
3149 (rev 80)
        Subsystem: VIA Technologies, Inc.: Unknown device 3149
        Flags: bus master, medium devsel, latency 32, IRQ 11
        I/O ports at 8800 [size=8]
        I/O ports at 8400 [size=4]
        I/O ports at 8000 [size=8]
        I/O ports at 7800 [size=4]
        I/O ports at 7400 [size=16]
        I/O ports at 7000 [size=256]
        Capabilities: [c0] Power Management version 2

-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: VIA Serial ATA chipset
       [not found] ` <20030811055522.31F6427A21@mail.medav.de>
@ 2003-08-11  6:06   ` Misha Nasledov
       [not found]     ` <20030811062839.76F9216F24@mail.medav.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Misha Nasledov @ 2003-08-11  6:06 UTC (permalink / raw)
  To: Daniela Engert; +Cc: linux-kernel

On Mon, Aug 11, 2003 at 07:55:49AM +0200, Daniela Engert wrote:
> It's looking very similar to the standard ATA host register model, so
> it's probably nearly identical to existing VIA PATA controllers. To
> check this we need to know the actual PCI config space. What does lspci
> -s 0:f.0 -vvxx show?

Here is the output:
00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device
3149 (rev 80)
        Subsystem: VIA Technologies, Inc.: Unknown device 3149
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at 8800 [size=8]
        Region 1: I/O ports at 8400 [size=4]
        Region 2: I/O ports at 8000 [size=8]
        Region 3: I/O ports at 7800 [size=4]
        Region 4: I/O ports at 7400 [size=16]
        Region 5: I/O ports at 7000 [size=256]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 49 31 07 00 90 02 80 00 04 01 00 20 80 00
10: 01 88 00 00 01 84 00 00 01 80 00 00 01 78 00 00
20: 01 74 00 00 01 70 00 00 00 00 00 00 06 11 49 31
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 01 00 00

Also, if SATA were to work, would there be any problem with accessing
the hard disk? Currently, I have two onboard IDE channels, a PCI IDE
card, and this SATA chip. I notice that the IDE hard disk devices only
go up to hdh in /dev. Would I be able to use all 6 of my IDE channels?
-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: VIA Serial ATA chipset
       [not found]     ` <20030811062839.76F9216F24@mail.medav.de>
@ 2003-08-11  6:34       ` Misha Nasledov
       [not found]         ` <20030811064757.7B1CF1C92C@mail.medav.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Misha Nasledov @ 2003-08-11  6:34 UTC (permalink / raw)
  To: Daniela Engert; +Cc: linux-kernel

On Mon, Aug 11, 2003 at 08:29:07AM +0200, Daniela Engert wrote:
> Thanks. I'm sorry, my fault. It should have read "lspci -s 0:f.0
> -vvxxx" as root. This will show the full 256 bytes PCI config space.

00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device
3149 (rev 80)
        Subsystem: VIA Technologies, Inc.: Unknown device 3149
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Step                         
ping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort                         
- <MAbort- >SERR- <PERR-
        Latency: 32
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at 8800 [size=8]
        Region 1: I/O ports at 8400 [size=4]
        Region 2: I/O ports at 8000 [size=8]
        Region 3: I/O ports at 7800 [size=4]
        Region 4: I/O ports at 7400 [size=16]
        Region 5: I/O ports at 7000 [size=256]
        Capabilities: [c0] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot                         
-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 49 31 07 00 90 02 80 00 04 01 00 20 80 00
10: 01 88 00 00 01 84 00 00 01 80 00 00 01 78 00 00
20: 01 74 00 00 01 70 00 00 00 00 00 00 06 11 49 31
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 01 00 00
40: 13 03 f1 44 0e af 00 00 00 82 65 03 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 10 10 00 05 00 30 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 01 00 01 00 11 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 80 01 49 31 06 11 49 31 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: VIA Serial ATA chipset
       [not found]         ` <20030811064757.7B1CF1C92C@mail.medav.de>
@ 2003-08-11 22:34           ` Misha Nasledov
       [not found]             ` <20030812111332.351001ACFB@mail.medav.de>
  0 siblings, 1 reply; 10+ messages in thread
From: Misha Nasledov @ 2003-08-11 22:34 UTC (permalink / raw)
  To: Daniela Engert; +Cc: linux-kernel

On Mon, Aug 11, 2003 at 08:48:25AM +0200, Daniela Engert wrote:
> Ok, fine. This device should work at least in generic PCI IDE busmaster
> mode - even at full speed because of SATA.

Do I need to enable anything specific? I realized that I had neglected
to get the proper SATA power cable, so I just got one and I plugged in
my new SATA drive. There is no indication in my dmesg of any SATA
chipset or any connected SATA drives. I have the "Generic IDE
chipsets" option enabled, along with the PDC2026XX IDE card and the
VIA82CXXX chipset.
-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: VIA Serial ATA chipset
       [not found]             ` <20030812111332.351001ACFB@mail.medav.de>
@ 2003-08-13  6:49               ` Misha Nasledov
  2003-08-13  7:46                 ` Daniela Engert
  0 siblings, 1 reply; 10+ messages in thread
From: Misha Nasledov @ 2003-08-13  6:49 UTC (permalink / raw)
  To: Daniela Engert; +Cc: linux-kernel

Thanks a lot, this patch works for me. I have the following in my dmesg:

VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
PCI: Found IRQ 3 for device 0000:00:0f.0
IRQ routing conflict for 0000:00:0f.0, have irq 11, want irq 3
PCI: Sharing IRQ 3 with 0000:00:0f.1
IRQ routing conflict for 0000:00:10.0, have irq 11, want irq 3
IRQ routing conflict for 0000:00:10.1, have irq 11, want irq 3
VIA8237SATA: chipset revision 128
VIA8237SATA: 100% native mode on irq 11
    ide4: BM-DMA at 0x8400-0x8407, BIOS settings: hdi:pio, hdj:pio
    ide5: BM-DMA at 0x8408-0x840f, BIOS settings: hdk:pio, hdl:pio

The IRQ routing conflict lines have always existed, and there are more
similar lines in other parts of the dmesg. I'm not sure if they are
pertinent at all. Unfortunately, the drive does not seem to perform as
well as a SATA drive should; my UDMA/133 drive currently outperforms
this. However, it seems to significantly faster than the UDMA/66 drive
I run Linux on, so I am glad that it works as fast it does because now
I can perhaps use this as my new system drive.

Are there any plans on the horizon for a more complete driver for this
chipset?

On Tue, Aug 12, 2003 at 01:13:59PM +0200, Daniela Engert wrote:
> Looking at the sources of /drivers/ide/pci/generic.* shows that the
> "generic" driver is much less generic than its name might suggest. The
> following patch should help.
> 
> Ciao,
>   Dani
> 
> --- generic.c	Tue Aug 12 07:58:08 2003
> +++ generic.c	Tue Aug 12 12:59:02 2003
> @@ -140,6 +140,7 @@
> 	{ PCI_VENDOR_ID_HINT,	PCI_DEVICE_ID_HINT_VXPROII_IDE,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6},
> 	{ PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C561,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 7},
> 	{ PCI_VENDOR_ID_OPTI,	PCI_DEVICE_ID_OPTI_82C558,
>   PCI_ANY_ID, PCI_ANY_ID, 0, 0, 8},
> +	 { PCI_VENDOR_ID_VIA,
> PCI_DEVICE_ID_VIA_8237_SATA,	    PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> 9},
> 	{ 0, },
>  };
> 
> --- generic.h	Mon Jul 14 03:30:48 2003
> +++ generic.h	Tue Aug 12 13:02:08 2003
> @@ -127,7 +127,20 @@
> 		.enablebits	= {{0x00,0x00,0x00},
> {0x00,0x00,0x00}},
> 		.bootable	= ON_BOARD,
> 		.extra		= 0,
> -	},{
> +	 },{	 /* 9 */
> +		 .vendor	 = PCI_VENDOR_ID_VIA,
> +		 .device	 = PCI_DEVICE_ID_VIA_8237_SATA,
> +		 .name		 = "VIA8237SATA",
> +		.init_chipset	= init_chipset_generic,
> +		.init_iops	= NULL,
> +		.init_hwif	= init_hwif_generic,
> +		.init_dma	= init_dma_generic,
> +		.channels	= 2,
> +		 .autodma	 = AUTODMA,
> +		.enablebits	= {{0x00,0x00,0x00},
> {0x00,0x00,0x00}},
> +		 .bootable	 = OFF_BOARD,
> +		.extra		= 0,
> +	 },{
> 		.vendor 	= 0,
> 		.device 	= 0,
> 		.channels	= 0,
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Daniela Engert, systems engineer at MEDAV GmbH
> Gr?fenberger Str. 32-34, 91080 Uttenreuth, Germany
> Phone ++49-9131-583-348, Fax ++49-9131-583-11
> 
> 

-- 
Misha Nasledov
misha@nasledov.com
http://nasledov.com/misha/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: VIA Serial ATA chipset
  2003-08-13  6:49               ` Misha Nasledov
@ 2003-08-13  7:46                 ` Daniela Engert
  2003-08-29 14:51                   ` libata update posted (was Re: VIA Serial ATA chipset) Jeff Garzik
  0 siblings, 1 reply; 10+ messages in thread
From: Daniela Engert @ 2003-08-13  7:46 UTC (permalink / raw)
  To: Misha Nasledov; +Cc: Jeff Garzik, linux-kernel

On Tue, 12 Aug 2003 23:49:23 -0700, Misha Nasledov wrote:

>Thanks a lot, this patch works for me. I have the following in my dmesg:
>
>VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
>PCI: Found IRQ 3 for device 0000:00:0f.0
>IRQ routing conflict for 0000:00:0f.0, have irq 11, want irq 3
>PCI: Sharing IRQ 3 with 0000:00:0f.1
>IRQ routing conflict for 0000:00:10.0, have irq 11, want irq 3
>IRQ routing conflict for 0000:00:10.1, have irq 11, want irq 3
>VIA8237SATA: chipset revision 128
>VIA8237SATA: 100% native mode on irq 11
>    ide4: BM-DMA at 0x8400-0x8407, BIOS settings: hdi:pio, hdj:pio
>    ide5: BM-DMA at 0x8408-0x840f, BIOS settings: hdk:pio, hdl:pio
>
>The IRQ routing conflict lines have always existed, and there are more
>similar lines in other parts of the dmesg. I'm not sure if they are
>pertinent at all. Unfortunately, the drive does not seem to perform as
>well as a SATA drive should; my UDMA/133 drive currently outperforms
>this. However, it seems to significantly faster than the UDMA/66 drive
>I run Linux on, so I am glad that it works as fast it does because now
>I can perhaps use this as my new system drive.

Well, the patch was meant to be a quick shot from the hips only, just
to get your system going and to check if my assumptions about the
structure of the VIA SATA host controller implementation wer correct.
It looks like they are, this controller seems to follow the T13 ATA
host controller model.

>Are there any plans on the horizon for a more complete driver for this
>chipset?

Jeff Garzik is working on a SATA driver. My conclusions from the
results of the feasability test above are that adding the VIA SATA
controller to the already existing libata source should boil down to
pretty simple programming excercise.

Ciao,
  Dani


>On Tue, Aug 12, 2003 at 01:13:59PM +0200, Daniela Engert wrote:
>> Looking at the sources of /drivers/ide/pci/generic.* shows that the
>> "generic" driver is much less generic than its name might suggest. The
>> following patch should help.
>> 
>> Ciao,
>>   Dani
>> 
>> --- generic.c	Tue Aug 12 07:58:08 2003
>> +++ generic.c	Tue Aug 12 12:59:02 2003
>> @@ -140,6 +140,7 @@
>> 	{ PCI_VENDOR_ID_HINT,	PCI_DEVICE_ID_HINT_VXPROII_IDE,
>> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 6},
>> 	{ PCI_VENDOR_ID_VIA,	PCI_DEVICE_ID_VIA_82C561,
>> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 7},
>> 	{ PCI_VENDOR_ID_OPTI,	PCI_DEVICE_ID_OPTI_82C558,
>>   PCI_ANY_ID, PCI_ANY_ID, 0, 0, 8},
>> +	 { PCI_VENDOR_ID_VIA,
>> PCI_DEVICE_ID_VIA_8237_SATA,	    PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>> 9},
>> 	{ 0, },
>>  };
>> 
>> --- generic.h	Mon Jul 14 03:30:48 2003
>> +++ generic.h	Tue Aug 12 13:02:08 2003
>> @@ -127,7 +127,20 @@
>> 		.enablebits	= {{0x00,0x00,0x00},
>> {0x00,0x00,0x00}},
>> 		.bootable	= ON_BOARD,
>> 		.extra		= 0,
>> -	},{
>> +	 },{	 /* 9 */
>> +		 .vendor	 = PCI_VENDOR_ID_VIA,
>> +		 .device	 = PCI_DEVICE_ID_VIA_8237_SATA,
>> +		 .name		 = "VIA8237SATA",
>> +		.init_chipset	= init_chipset_generic,
>> +		.init_iops	= NULL,
>> +		.init_hwif	= init_hwif_generic,
>> +		.init_dma	= init_dma_generic,
>> +		.channels	= 2,
>> +		 .autodma	 = AUTODMA,
>> +		.enablebits	= {{0x00,0x00,0x00},
>> {0x00,0x00,0x00}},
>> +		 .bootable	 = OFF_BOARD,
>> +		.extra		= 0,
>> +	 },{
>> 		.vendor 	= 0,
>> 		.device 	= 0,
>> 		.channels	= 0,
>> 
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Daniela Engert, systems engineer at MEDAV GmbH
>> Gr?fenberger Str. 32-34, 91080 Uttenreuth, Germany
>> Phone ++49-9131-583-348, Fax ++49-9131-583-11
>> 
>> 
>
>-- 
>Misha Nasledov
>misha@nasledov.com
>http://nasledov.com/misha/
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Daniela Engert, systems engineer at MEDAV GmbH
Gräfenberger Str. 32-34, 91080 Uttenreuth, Germany
Phone ++49-9131-583-348, Fax ++49-9131-583-11



^ permalink raw reply	[flat|nested] 10+ messages in thread

* libata update posted (was Re: VIA Serial ATA chipset)
  2003-08-13  7:46                 ` Daniela Engert
@ 2003-08-29 14:51                   ` Jeff Garzik
  2003-08-29 17:21                     ` Samuel Flory
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff Garzik @ 2003-08-29 14:51 UTC (permalink / raw)
  To: linux-kernel, SCSI Mailing List; +Cc: Daniela Engert, Misha Nasledov

[-- Attachment #1: Type: text/plain, Size: 2971 bytes --]

Daniela Engert wrote:
> On Tue, 12 Aug 2003 23:49:23 -0700, Misha Nasledov wrote:
> 
> 
>>Thanks a lot, this patch works for me. I have the following in my dmesg:
>>
>>VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
>>PCI: Found IRQ 3 for device 0000:00:0f.0
>>IRQ routing conflict for 0000:00:0f.0, have irq 11, want irq 3
>>PCI: Sharing IRQ 3 with 0000:00:0f.1
>>IRQ routing conflict for 0000:00:10.0, have irq 11, want irq 3
>>IRQ routing conflict for 0000:00:10.1, have irq 11, want irq 3
>>VIA8237SATA: chipset revision 128
>>VIA8237SATA: 100% native mode on irq 11
>>   ide4: BM-DMA at 0x8400-0x8407, BIOS settings: hdi:pio, hdj:pio
>>   ide5: BM-DMA at 0x8408-0x840f, BIOS settings: hdk:pio, hdl:pio
>>
>>The IRQ routing conflict lines have always existed, and there are more
>>similar lines in other parts of the dmesg. I'm not sure if they are
>>pertinent at all. Unfortunately, the drive does not seem to perform as
>>well as a SATA drive should; my UDMA/133 drive currently outperforms
>>this. However, it seems to significantly faster than the UDMA/66 drive
>>I run Linux on, so I am glad that it works as fast it does because now
>>I can perhaps use this as my new system drive.
> 
> 
> Well, the patch was meant to be a quick shot from the hips only, just
> to get your system going and to check if my assumptions about the
> structure of the VIA SATA host controller implementation wer correct.
> It looks like they are, this controller seems to follow the T13 ATA
> host controller model.

Correct.


>>Are there any plans on the horizon for a more complete driver for this
>>chipset?
> 
> 
> Jeff Garzik is working on a SATA driver. My conclusions from the
> results of the feasability test above are that adding the VIA SATA
> controller to the already existing libata source should boil down to
> pretty simple programming excercise.

It was.  The sata_via.c driver is absolutely generic except for its PCI 
ID.  I only chose to create a separate driver because I now have docs 
(thanks, VIA), so I can begin programming the SATA-specific registers.

So, here are the 2.4 and 2.6 versions of the VIA SATA support for 
libata, contained in the latest libata update.

2.4 BK: bk://kernel.bkbits.net/jgarzik/atascsi-2.4
2.4 Patch: 
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.23-pre1-libata3.patch.bz2

2.6 BK: bk://kernel.bkbits.net/jgarzik/atascsi-2.6
2.6 Patch: 
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test4-bk2-libata3.patch.bz2


Changes:
* add VIA SATA driver
* fixes to software reset.
* other fixes
* split scsi-related code into separate file, libata-scsi.c.
* continue work on phy layer
* continue work towards fully async taskfile API:  you call submit_tf(), 
and later on, your callback is called when the taskfile completes or 
times out.   async taskfile API is required for ATAPI and supporting 
more advanced host controllers like Promise or AHCI (SATA2).
* some cleanups


[-- Attachment #2: patch.srst --]
[-- Type: text/plain, Size: 1029 bytes --]

===== drivers/scsi/ata_piix.c 1.22 vs edited =====
--- 1.22/drivers/scsi/ata_piix.c	Thu Aug 28 22:07:27 2003
+++ edited/drivers/scsi/ata_piix.c	Fri Aug 29 00:51:44 2003
@@ -137,7 +137,7 @@
 	/* ich5_pata */
 	{
 		.sht		= &piix_sht,
-		.host_flags	= ATA_FLAG_SLAVE_POSS,
+		.host_flags	= ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
 		.pio_mask	= 0x03,	/* pio3-4 */
 		.udma_mask	= ATA_UDMA_MASK_40C, /* FIXME: cbl det */
 		.host_info	= &piix_pata_ops,
@@ -146,7 +146,8 @@
 	/* ich5_sata */
 	{
 		.sht		= &piix_sht,
-		.host_flags	= ATA_FLAG_SATA | PIIX_FLAG_COMBINED,
+		.host_flags	= ATA_FLAG_SATA | PIIX_FLAG_COMBINED
+				  | ATA_FLAG_SRST,
 		.pio_mask	= 0x03,	/* pio3-4 */
 		.udma_mask	= 0x7f,	/* udma0-6 ; FIXME */
 		.host_info	= &piix_sata_ops,
@@ -155,7 +156,7 @@
 	/* piix4_pata */
 	{
 		.sht		= &piix_sht,
-		.host_flags	= ATA_FLAG_SLAVE_POSS,
+		.host_flags	= ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
 		.pio_mask	= 0x03, /* pio3-4 */
 		.udma_mask	= ATA_UDMA_MASK_40C, /* FIXME: cbl det */
 		.host_info	= &piix_pata_ops,

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: libata update posted (was Re: VIA Serial ATA chipset)
  2003-08-29 14:51                   ` libata update posted (was Re: VIA Serial ATA chipset) Jeff Garzik
@ 2003-08-29 17:21                     ` Samuel Flory
  2003-08-29 17:59                       ` Jeff Garzik
  0 siblings, 1 reply; 10+ messages in thread
From: Samuel Flory @ 2003-08-29 17:21 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-kernel, SCSI Mailing List

Jeff Garzik wrote:

>
> So, here are the 2.4 and 2.6 versions of the VIA SATA support for 
> libata, contained in the latest libata update.
>
> 2.4 BK: bk://kernel.bkbits.net/jgarzik/atascsi-2.4
> 2.4 Patch: 
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.23-pre1-libata3.patch.bz2 
>
>
> 2.6 BK: bk://kernel.bkbits.net/jgarzik/atascsi-2.6
> 2.6 Patch: 
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/2.6.0-test4-bk2-libata3.patch.bz2 
>
>
>
> Changes:
> * add VIA SATA driver
> * fixes to software reset.
> * other fixes
> * split scsi-related code into separate file, libata-scsi.c.
> * continue work on phy layer
> * continue work towards fully async taskfile API:  you call 
> submit_tf(), and later on, your callback is called when the taskfile 
> completes or times out.   async taskfile API is required for ATAPI and 
> supporting more advanced host controllers like Promise or AHCI (SATA2).
> * some cleanups
>
>  
>

   I'm guessing there is no support for Promise yet? 

  I'm just asking because I've got this dual amd64 with 4 Promise sata 
ports.  Which for some reason there aren't drivers any 64 bit OS;-(


PS-  The driver works great on the silcon image chipset.  (Once I 
realized that my Seagate drive needed newer firmware.)

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: libata update posted (was Re: VIA Serial ATA chipset)
  2003-08-29 17:21                     ` Samuel Flory
@ 2003-08-29 17:59                       ` Jeff Garzik
  2003-08-29 18:09                         ` Samuel Flory
  0 siblings, 1 reply; 10+ messages in thread
From: Jeff Garzik @ 2003-08-29 17:59 UTC (permalink / raw)
  To: Samuel Flory; +Cc: linux-kernel, SCSI Mailing List

Samuel Flory wrote:
> Jeff Garzik wrote:
>> Changes:
>> * continue work towards fully async taskfile API:  you call 
>> submit_tf(), and later on, your callback is called when the taskfile 
>> completes or times out.   async taskfile API is required for ATAPI and 
>> supporting more advanced host controllers like Promise or AHCI (SATA2).
>> * some cleanups

>   I'm guessing there is no support for Promise yet?

Not yet.  Once I finish the item mentioned above, "async taskfile API", 
Promise support will appear quite rapidly.


> PS-  The driver works great on the silcon image chipset.  (Once I 
> realized that my Seagate drive needed newer firmware.)

Um... libata doesn't support Silicon Image yet?

	Jeff




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: libata update posted (was Re: VIA Serial ATA chipset)
  2003-08-29 17:59                       ` Jeff Garzik
@ 2003-08-29 18:09                         ` Samuel Flory
  0 siblings, 0 replies; 10+ messages in thread
From: Samuel Flory @ 2003-08-29 18:09 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: linux-kernel, SCSI Mailing List

Jeff Garzik wrote:

> Samuel Flory wrote:
>
>> Jeff Garzik wrote:
>>
>>> Changes:
>>> * continue work towards fully async taskfile API:  you call 
>>> submit_tf(), and later on, your callback is called when the taskfile 
>>> completes or times out.   async taskfile API is required for ATAPI 
>>> and supporting more advanced host controllers like Promise or AHCI 
>>> (SATA2).
>>> * some cleanups
>>
>
>>   I'm guessing there is no support for Promise yet?
>
>
> Not yet.  Once I finish the item mentioned above, "async taskfile 
> API", Promise support will appear quite rapidly.
>
>
>> PS-  The driver works great on the silcon image chipset.  (Once I 
>> realized that my Seagate drive needed newer firmware.)
>
>
> Um... libata doesn't support Silicon Image yet?
>


  The Intel PIIX/ICH support in the ac kernel seems to work on all my 
onboard  Silicon Image controllers.  I think that's only your ata-scsi 
work, however.

-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>



^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2003-08-29 18:16 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-11  2:17 VIA Serial ATA chipset Misha Nasledov
     [not found] ` <20030811055522.31F6427A21@mail.medav.de>
2003-08-11  6:06   ` Misha Nasledov
     [not found]     ` <20030811062839.76F9216F24@mail.medav.de>
2003-08-11  6:34       ` Misha Nasledov
     [not found]         ` <20030811064757.7B1CF1C92C@mail.medav.de>
2003-08-11 22:34           ` Misha Nasledov
     [not found]             ` <20030812111332.351001ACFB@mail.medav.de>
2003-08-13  6:49               ` Misha Nasledov
2003-08-13  7:46                 ` Daniela Engert
2003-08-29 14:51                   ` libata update posted (was Re: VIA Serial ATA chipset) Jeff Garzik
2003-08-29 17:21                     ` Samuel Flory
2003-08-29 17:59                       ` Jeff Garzik
2003-08-29 18:09                         ` Samuel Flory

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).