PCI SATA controllers on embedded, no-BIOS targets

PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

I have a Silicon Images 3112 PCI card on an XScale IXP425 platform.  The 
card works well in a PC, but I haven't got it to work in on the ARM 
platform.  On the PC, I see the cards BIOS executed and am guessing that 
since this can't happen on the ARM, that's why things aren't working.

The card is at least detected on the ARM, and the driver tries to probe 
for devices, but times out an moves on.

Before I debug this too deeply, I want to make sure this should work on 
embedded boards, even without the BIOS execution.

Thanks,
Kevin

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Kevin Hilman wrote:
> I have a Silicon Images 3112 PCI card on an XScale IXP425 platform.  The 
> card works well in a PC, but I haven't got it to work in on the ARM 
> platform.  On the PC, I see the cards BIOS executed and am guessing that 
> since this can't happen on the ARM, that's why things aren't working.
> 
> The card is at least detected on the ARM, and the driver tries to probe 
> for devices, but times out an moves on.
> 
> Before I debug this too deeply, I want to make sure this should work on 
> embedded boards, even without the BIOS execution.

sil3112 works fine w/o any BIOS initialization.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

Tejun Heo wrote:
> Kevin Hilman wrote:
>> I have a Silicon Images 3112 PCI card on an XScale IXP425 platform.  
>> The card works well in a PC, but I haven't got it to work in on the 
>> ARM platform.  On the PC, I see the cards BIOS executed and am 
>> guessing that since this can't happen on the ARM, that's why things 
>> aren't working.
>>
>> The card is at least detected on the ARM, and the driver tries to 
>> probe for devices, but times out an moves on.
>>
>> Before I debug this too deeply, I want to make sure this should work 
>> on embedded boards, even without the BIOS execution.
> 
> sil3112 works fine w/o any BIOS initialization.
> 

I'm curious what platforms this has been tested.  Any non-x86 platforms? 
  Any big endian platforms?

Thanks for the quick response.

Kevin

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Kevin Hilman wrote:
> Tejun Heo wrote:
>> Kevin Hilman wrote:
>>> I have a Silicon Images 3112 PCI card on an XScale IXP425 platform.  
>>> The card works well in a PC, but I haven't got it to work in on the 
>>> ARM platform.  On the PC, I see the cards BIOS executed and am 
>>> guessing that since this can't happen on the ARM, that's why things 
>>> aren't working.
>>>
>>> The card is at least detected on the ARM, and the driver tries to 
>>> probe for devices, but times out an moves on.
>>>
>>> Before I debug this too deeply, I want to make sure this should work 
>>> on embedded boards, even without the BIOS execution.
>>
>> sil3112 works fine w/o any BIOS initialization.
>>
> 
> I'm curious what platforms this has been tested.  Any non-x86 platforms? 
>  Any big endian platforms?
> 
> Thanks for the quick response.

I've personally seen it working on XScale and ATI's mips.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Tejun Heo wrote:
> Kevin Hilman wrote:
>> Tejun Heo wrote:
>>> Kevin Hilman wrote:
>>>> I have a Silicon Images 3112 PCI card on an XScale IXP425 platform.  
>>>> The card works well in a PC, but I haven't got it to work in on the 
>>>> ARM platform.  On the PC, I see the cards BIOS executed and am 
>>>> guessing that since this can't happen on the ARM, that's why things 
>>>> aren't working.
>>>>
>>>> The card is at least detected on the ARM, and the driver tries to 
>>>> probe for devices, but times out an moves on.
>>>>
>>>> Before I debug this too deeply, I want to make sure this should work 
>>>> on embedded boards, even without the BIOS execution.
>>>
>>> sil3112 works fine w/o any BIOS initialization.
>>>
>>
>> I'm curious what platforms this has been tested.  Any non-x86 
>> platforms?  Any big endian platforms?
>>
>> Thanks for the quick response.
> 
> I've personally seen it working on XScale and ATI's mips.

For the record, for ATI's new mips platform, sata_sil needs some 
modifications.  Their PCI bridge can't handle byte-aligned mmio and the 
driver had to be modified to use IO address space.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

Tejun Heo wrote:
> Tejun Heo wrote:
>> Kevin Hilman wrote:
>>> Tejun Heo wrote:
>>>> Kevin Hilman wrote:
>>>>> I have a Silicon Images 3112 PCI card on an XScale IXP425 
>>>>> platform.  The card works well in a PC, but I haven't got it to 
>>>>> work in on the ARM platform.  On the PC, I see the cards BIOS 
>>>>> executed and am guessing that since this can't happen on the ARM, 
>>>>> that's why things aren't working.
>>>>>
>>>>> The card is at least detected on the ARM, and the driver tries to 
>>>>> probe for devices, but times out an moves on.
>>>>>
>>>>> Before I debug this too deeply, I want to make sure this should 
>>>>> work on embedded boards, even without the BIOS execution.
>>>>
>>>> sil3112 works fine w/o any BIOS initialization.
>>>>
>>>
>>> I'm curious what platforms this has been tested.  Any non-x86 
>>> platforms?  Any big endian platforms?
>>>
>>> Thanks for the quick response.
>>
>> I've personally seen it working on XScale and ATI's mips.

OK, that's good to know.

> For the record, for ATI's new mips platform, sata_sil needs some 
> modifications.  Their PCI bridge can't handle byte-aligned mmio and the 
> driver had to be modified to use IO address space.

I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
(drivers/scsi/sata_sil.c) cause crashes during probing due to bad memory 
accesses.

Switching the legacy driver into PIO mode makes the probing work well, 
but still can't figure out what's happening in the libata driver, AFICT, 
it can't do PIO.

Any chance you can share the changes to use IO address space?  Maybe the 
PCI on this XScale has similar limitations.

Kevin

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

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

Kevin Hilman wrote:
>>> I've personally seen it working on XScale and ATI's mips.
> 
> OK, that's good to know.
> 
>> For the record, for ATI's new mips platform, sata_sil needs some 
>> modifications.  Their PCI bridge can't handle byte-aligned mmio and 
>> the driver had to be modified to use IO address space.
> 
> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
> legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad memory 
> accesses.

So, that one can't do byte-aligned mmio either?

> Switching the legacy driver into PIO mode makes the probing work well, 
> but still can't figure out what's happening in the libata driver, AFICT, 
> it can't do PIO.

By PIO, you mean accessing registers via IO address space instead of 
memory address space, right?  Not PIO as opposed to DMA.

> Any chance you can share the changes to use IO address space?  Maybe the 
> PCI on this XScale has similar limitations.

Sure, I've just got okay for releasing the code and am going to post the 
patches on my website anyway.  I'm attaching a patch.  This might not 
apply cleanly to your kernel but it should give enough idea.  Oh the 
code kills 4 ports support for 3114 too.

-- 
tejun

[-- Attachment #2: use-pio-instead-of-mmio --]
[-- Type: text/plain, Size: 4155 bytes --]

Index: work1/drivers/scsi/sata_sil.c
===================================================================
--- work1.orig/drivers/scsi/sata_sil.c	2006-06-14 10:44:43.000000000 +0900
+++ work1/drivers/scsi/sata_sil.c	2006-06-15 19:15:08.000000000 +0900
@@ -57,14 +57,10 @@ enum {
 	sil_3512		= 2,
 	sil_3114		= 3,
 
-	SIL_FIFO_R0		= 0x40,
-	SIL_FIFO_W0		= 0x41,
-	SIL_FIFO_R1		= 0x44,
-	SIL_FIFO_W1		= 0x45,
-	SIL_FIFO_R2		= 0x240,
-	SIL_FIFO_W2		= 0x241,
-	SIL_FIFO_R3		= 0x244,
-	SIL_FIFO_W3		= 0x245,
+	SIL_FIFO_0		= 0x40,
+	SIL_FIFO_1		= 0x44,
+	SIL_FIFO_2		= 0x240,
+	SIL_FIFO_3		= 0x244,
 
 	SIL_SYSCFG		= 0x48,
 	SIL_MASK_IDE0_INT	= (1 << 22),
@@ -181,7 +177,7 @@ static const struct ata_port_info sil_po
 	{
 		.sht		= &sil_sht,
 		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
-				  ATA_FLAG_SRST | ATA_FLAG_MMIO,
+				  ATA_FLAG_SRST,
 		.pio_mask	= 0x1f,			/* pio0-4 */
 		.mwdma_mask	= 0x07,			/* mwdma0-2 */
 		.udma_mask	= 0x3f,			/* udma0-5 */
@@ -191,8 +187,7 @@ static const struct ata_port_info sil_po
 	{
 		.sht		= &sil_sht,
 		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
-				  ATA_FLAG_SRST | ATA_FLAG_MMIO |
-				  SIL_FLAG_MOD15WRITE,
+				  ATA_FLAG_SRST | SIL_FLAG_MOD15WRITE,
 		.pio_mask	= 0x1f,			/* pio0-4 */
 		.mwdma_mask	= 0x07,			/* mwdma0-2 */
 		.udma_mask	= 0x3f,			/* udma0-5 */
@@ -202,8 +197,7 @@ static const struct ata_port_info sil_po
 	{
 		.sht		= &sil_sht,
 		.host_flags	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
-				  ATA_FLAG_SRST | ATA_FLAG_MMIO |
-				  SIL_FLAG_RERR_ON_DMA_ACT,
+				  ATA_FLAG_SRST | SIL_FLAG_RERR_ON_DMA_ACT,
 		.pio_mask	= 0x1f,			/* pio0-4 */
 		.mwdma_mask	= 0x07,			/* mwdma0-2 */
 		.udma_mask	= 0x3f,			/* udma0-5 */
@@ -459,13 +453,34 @@ static int sil_init_one (struct pci_dev 
 
 	base = (unsigned long) mmio_base;
 
-	for (i = 0; i < probe_ent->n_ports; i++) {
-		probe_ent->port[i].cmd_addr = base + sil_port[i].tf;
-		probe_ent->port[i].altstatus_addr =
-		probe_ent->port[i].ctl_addr = base + sil_port[i].ctl;
-		probe_ent->port[i].bmdma_addr = base + sil_port[i].bmdma;
-		probe_ent->port[i].scr_addr = base + sil_port[i].scr;
-		ata_std_ports(&probe_ent->port[i]);
+	if (ent->driver_data == 3114) {
+		for (i = 0; i < probe_ent->n_ports; i++) {
+			probe_ent->port[i].cmd_addr = base + sil_port[i].tf;
+			probe_ent->port[i].altstatus_addr =
+			probe_ent->port[i].ctl_addr = base + sil_port[i].ctl;
+			probe_ent->port[i].bmdma_addr = base + sil_port[i].bmdma;
+			probe_ent->port[i].scr_addr = base + sil_port[i].scr;
+			ata_std_ports(&probe_ent->port[i]);
+		}
+	} else {
+		/* Use PIO for 3112/3512.  Some platforms barf on
+		 * byte-wide mmio on odd boundary.
+		 */
+		probe_ent->port[0].cmd_addr = pci_resource_start(pdev, 0);
+		probe_ent->port[0].altstatus_addr =
+		probe_ent->port[0].ctl_addr =
+			pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
+		probe_ent->port[0].bmdma_addr = pci_resource_start(pdev, 4);
+		probe_ent->port[0].scr_addr = base + sil_port[0].scr;
+		ata_std_ports(&probe_ent->port[0]);
+
+		probe_ent->port[1].cmd_addr = pci_resource_start(pdev, 2);
+		probe_ent->port[1].altstatus_addr =
+		probe_ent->port[1].ctl_addr =
+			pci_resource_start(pdev, 3) | ATA_PCI_CTL_OFS;
+		probe_ent->port[1].bmdma_addr = pci_resource_start(pdev, 4) + 8;
+		probe_ent->port[1].scr_addr = base + sil_port[1].scr;
+		ata_std_ports(&probe_ent->port[1]);
 	}
 
 	/* Initialize FIFO PCI bus arbitration */
@@ -473,15 +488,12 @@ static int sil_init_one (struct pci_dev 
 	if (cls) {
 		cls >>= 3;
 		cls++;  /* cls = (line_size/8)+1 */
-		writeb(cls, mmio_base + SIL_FIFO_R0);
-		writeb(cls, mmio_base + SIL_FIFO_W0);
-		writeb(cls, mmio_base + SIL_FIFO_R1);
-		writeb(cls, mmio_base + SIL_FIFO_W1);
+		tmp = cls << 8 | cls;
+		writew(tmp, mmio_base + SIL_FIFO_0);
+		writew(tmp, mmio_base + SIL_FIFO_1);
 		if (ent->driver_data == sil_3114) {
-			writeb(cls, mmio_base + SIL_FIFO_R2);
-			writeb(cls, mmio_base + SIL_FIFO_W2);
-			writeb(cls, mmio_base + SIL_FIFO_R3);
-			writeb(cls, mmio_base + SIL_FIFO_W3);
+			writew(tmp, mmio_base + SIL_FIFO_2);
+			writew(tmp, mmio_base + SIL_FIFO_3);
 		}
 	} else
 		dev_printk(KERN_WARNING, &pdev->dev,

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Tejun Heo wrote:
> Kevin Hilman wrote:
>>>> I've personally seen it working on XScale and ATI's mips.
>>
>> OK, that's good to know.
>>
>>> For the record, for ATI's new mips platform, sata_sil needs some 
>>> modifications.  Their PCI bridge can't handle byte-aligned mmio and 
>>> the driver had to be modified to use IO address space.
>>
>> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
>> legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
>> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad 
>> memory accesses.
> 
> So, that one can't do byte-aligned mmio either?
> 
>> Switching the legacy driver into PIO mode makes the probing work well, 
>> but still can't figure out what's happening in the libata driver, 
>> AFICT, it can't do PIO.
> 
> By PIO, you mean accessing registers via IO address space instead of 
> memory address space, right?  Not PIO as opposed to DMA.
> 
>> Any chance you can share the changes to use IO address space?  Maybe 
>> the PCI on this XScale has similar limitations.
> 
> Sure, I've just got okay for releasing the code and am going to post the 
> patches on my website anyway.  I'm attaching a patch.  This might not 
> apply cleanly to your kernel but it should give enough idea.  Oh the 
> code kills 4 ports support for 3114 too.

s/kills/doesn't support/

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

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

Tejun Heo wrote:
> Kevin Hilman wrote:
>>>> I've personally seen it working on XScale and ATI's mips.
>>
>> OK, that's good to know.
>>
>>> For the record, for ATI's new mips platform, sata_sil needs some 
>>> modifications.  Their PCI bridge can't handle byte-aligned mmio and 
>>> the driver had to be modified to use IO address space.
>>
>> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
>> legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
>> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad 
>> memory accesses.
> 
> So, that one can't do byte-aligned mmio either?
> 
>> Switching the legacy driver into PIO mode makes the probing work well, 
>> but still can't figure out what's happening in the libata driver, 
>> AFICT, it can't do PIO.
> 
> By PIO, you mean accessing registers via IO address space instead of 
> memory address space, right?  Not PIO as opposed to DMA.

yes, I mean using PCI IO address space.

>> Any chance you can share the changes to use IO address space?  Maybe 
>> the PCI on this XScale has similar limitations.
> 
> Sure, I've just got okay for releasing the code and am going to post the 
> patches on my website anyway.  I'm attaching a patch.  This might not 
> apply cleanly to your kernel but it should give enough idea.  Oh the 
> code kills 4 ports support for 3114 too.

OK, tweaking your patch onto 2.6.18-rc4, I've got it to work using IO 
address space.  My patch attached for reference.  FYI, in addition to 
your changes, I also had to change the data_xfer method to use 
ata_pio_data_xfer instead of ata_mmio_data_xfer which was faulting since 
  my arch doesn't have direct memory access to IO space.

Kevin

[-- Attachment #2: sata_sil-use-pio-instead-of-mmio.patch --]
[-- Type: text/plain, Size: 2472 bytes --]

Index: dev/drivers/scsi/sata_sil.c
===================================================================
--- dev.orig/drivers/scsi/sata_sil.c
+++ dev/drivers/scsi/sata_sil.c
@@ -57,7 +57,7 @@ enum {
 	SIL_FLAG_MOD15WRITE	= (1 << 30),
 
 	SIL_DFL_HOST_FLAGS	= ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY |
-				  ATA_FLAG_MMIO | ATA_FLAG_HRST_TO_RESUME,
+				  ATA_FLAG_HRST_TO_RESUME,
 
 	/*
 	 * Controller IDs
@@ -200,7 +200,7 @@ static const struct ata_port_operations 
 	.bmdma_status		= ata_bmdma_status,
 	.qc_prep		= ata_qc_prep,
 	.qc_issue		= ata_qc_issue_prot,
-	.data_xfer		= ata_mmio_data_xfer,
+	.data_xfer		= ata_pio_data_xfer,
 	.freeze			= sil_freeze,
 	.thaw			= sil_thaw,
 	.error_handler		= ata_bmdma_error_handler,
@@ -670,13 +670,35 @@ static int sil_init_one (struct pci_dev 
 
 	base = (unsigned long) mmio_base;
 
-	for (i = 0; i < probe_ent->n_ports; i++) {
-		probe_ent->port[i].cmd_addr = base + sil_port[i].tf;
-		probe_ent->port[i].altstatus_addr =
-		probe_ent->port[i].ctl_addr = base + sil_port[i].ctl;
-		probe_ent->port[i].bmdma_addr = base + sil_port[i].bmdma;
-		probe_ent->port[i].scr_addr = base + sil_port[i].scr;
-		ata_std_ports(&probe_ent->port[i]);
+	if (ent->driver_data == sil_3114) {
+		for (i = 0; i < probe_ent->n_ports; i++) {
+			probe_ent->port[i].cmd_addr = base + sil_port[i].tf;
+			probe_ent->port[i].altstatus_addr =
+			probe_ent->port[i].ctl_addr = base + sil_port[i].ctl;
+			probe_ent->port[i].bmdma_addr = base + sil_port[i].bmdma;
+			probe_ent->port[i].scr_addr = base + sil_port[i].scr;
+			ata_std_ports(&probe_ent->port[i]);
+		}
+	} else {
+		/* Use PIO for 3112/3512.  Some platforms barf on
+		 * byte-wide mmio on odd boundary.
+		 */
+		probe_ent->port[0].cmd_addr = pci_resource_start(pdev, 0);
+		probe_ent->port[0].altstatus_addr =
+			probe_ent->port[0].ctl_addr =
+			pci_resource_start(pdev, 1) | ATA_PCI_CTL_OFS;
+		probe_ent->port[0].bmdma_addr = pci_resource_start(pdev, 4);
+		probe_ent->port[0].scr_addr = base + sil_port[0].scr;
+		ata_std_ports(&probe_ent->port[0]);
+ 
+		probe_ent->port[1].cmd_addr = pci_resource_start(pdev, 2);
+		probe_ent->port[1].altstatus_addr =
+			probe_ent->port[1].ctl_addr =
+			pci_resource_start(pdev, 3) | ATA_PCI_CTL_OFS;
+		probe_ent->port[1].bmdma_addr = pci_resource_start(pdev, 4) + 8;
+		probe_ent->port[1].scr_addr = base + sil_port[1].scr;
+		ata_std_ports(&probe_ent->port[1]);
+
 	}
 
 	sil_init_controller(pdev, probe_ent->n_ports, probe_ent->host_flags,

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Kevin Hilman wrote:
> Tejun Heo wrote:
>> Kevin Hilman wrote:
>>>>> I've personally seen it working on XScale and ATI's mips.
>>>
>>> OK, that's good to know.
>>>
>>>> For the record, for ATI's new mips platform, sata_sil needs some 
>>>> modifications.  Their PCI bridge can't handle byte-aligned mmio and 
>>>> the driver had to be modified to use IO address space.
>>>
>>> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
>>> legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
>>> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad 
>>> memory accesses.
>>
>> So, that one can't do byte-aligned mmio either?
>>
>>> Switching the legacy driver into PIO mode makes the probing work 
>>> well, but still can't figure out what's happening in the libata 
>>> driver, AFICT, it can't do PIO.
>>
>> By PIO, you mean accessing registers via IO address space instead of 
>> memory address space, right?  Not PIO as opposed to DMA.
> 
> yes, I mean using PCI IO address space.
> 
>>> Any chance you can share the changes to use IO address space?  Maybe 
>>> the PCI on this XScale has similar limitations.
>>
>> Sure, I've just got okay for releasing the code and am going to post 
>> the patches on my website anyway.  I'm attaching a patch.  This might 
>> not apply cleanly to your kernel but it should give enough idea.  Oh 
>> the code kills 4 ports support for 3114 too.
> 
> OK, tweaking your patch onto 2.6.18-rc4, I've got it to work using IO 
> address space.  My patch attached for reference.  FYI, in addition to 
> your changes, I also had to change the data_xfer method to use 
> ata_pio_data_xfer instead of ata_mmio_data_xfer which was faulting since 
>  my arch doesn't have direct memory access to IO space.

Ah... right.  ATI is okay with work/double word aligned PIO, so I didn't 
notice it.

Thanks.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Tejun Heo wrote:
> Kevin Hilman wrote:
>> Tejun Heo wrote:
>>> Kevin Hilman wrote:
>>>>>> I've personally seen it working on XScale and ATI's mips.
>>>>
>>>> OK, that's good to know.
>>>>
>>>>> For the record, for ATI's new mips platform, sata_sil needs some 
>>>>> modifications.  Their PCI bridge can't handle byte-aligned mmio and 
>>>>> the driver had to be modified to use IO address space.
>>>>
>>>> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the 
>>>> legacy driver (drivers/ide/pci/siimage.c) and the libata driver 
>>>> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad 
>>>> memory accesses.
>>>
>>> So, that one can't do byte-aligned mmio either?
>>>
>>>> Switching the legacy driver into PIO mode makes the probing work 
>>>> well, but still can't figure out what's happening in the libata 
>>>> driver, AFICT, it can't do PIO.
>>>
>>> By PIO, you mean accessing registers via IO address space instead of 
>>> memory address space, right?  Not PIO as opposed to DMA.
>>
>> yes, I mean using PCI IO address space.
>>
>>>> Any chance you can share the changes to use IO address space?  Maybe 
>>>> the PCI on this XScale has similar limitations.
>>>
>>> Sure, I've just got okay for releasing the code and am going to post 
>>> the patches on my website anyway.  I'm attaching a patch.  This might 
>>> not apply cleanly to your kernel but it should give enough idea.  Oh 
>>> the code kills 4 ports support for 3114 too.
>>
>> OK, tweaking your patch onto 2.6.18-rc4, I've got it to work using IO 
>> address space.  My patch attached for reference.  FYI, in addition to 
>> your changes, I also had to change the data_xfer method to use 
>> ata_pio_data_xfer instead of ata_mmio_data_xfer which was faulting 
>> since  my arch doesn't have direct memory access to IO space.
> 
> Ah... right.  ATI is okay with work/double word aligned PIO, so I didn't 
> notice it.

s/work/word/
s/PIO/mmio/

Sorry.  Just woke up and before coffee.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

Tejun Heo wrote:
> Kevin Hilman wrote:
>> Tejun Heo wrote:
>>> Kevin Hilman wrote:
>>>>>> I've personally seen it working on XScale and ATI's mips.
>>>>
>>>> OK, that's good to know.
>>>>
>>>>> For the record, for ATI's new mips platform, sata_sil needs some
>>>>> modifications.  Their PCI bridge can't handle byte-aligned mmio and
>>>>> the driver had to be modified to use IO address space.
>>>>
>>>> I'm using 2.6.18-rc4 on this XScale IXP425 (big endian) and both the
>>>> legacy driver (drivers/ide/pci/siimage.c) and the libata driver
>>>> (drivers/scsi/sata_sil.c) cause crashes during probing due to bad
>>>> memory accesses.
>>>
>>> So, that one can't do byte-aligned mmio either?
>>>
>>>> Switching the legacy driver into PIO mode makes the probing work
>>>> well, but still can't figure out what's happening in the libata
>>>> driver, AFICT, it can't do PIO.
>>>
>>> By PIO, you mean accessing registers via IO address space instead of
>>> memory address space, right?  Not PIO as opposed to DMA.
>>
>> yes, I mean using PCI IO address space.
>>
>>>> Any chance you can share the changes to use IO address space?  Maybe
>>>> the PCI on this XScale has similar limitations.
>>>
>>> Sure, I've just got okay for releasing the code and am going to post
>>> the patches on my website anyway.  I'm attaching a patch.  This might
>>> not apply cleanly to your kernel but it should give enough idea.  Oh
>>> the code kills 4 ports support for 3114 too.
>>
>> OK, tweaking your patch onto 2.6.18-rc4, I've got it to work using IO
>> address space.  My patch attached for reference.  FYI, in addition to
>> your changes, I also had to change the data_xfer method to use
>> ata_pio_data_xfer instead of ata_mmio_data_xfer which was faulting
>> since  my arch doesn't have direct memory access to IO space.
> 
> Ah... right.  ATI is okay with work/double word aligned PIO, so I didn't
> notice it.

I've now been using a patched sata_sil driver for a while to support PCI
IO space on my embedded ARM target.  Do you have any plans of pushing
support for this upstream?

Kevin

Re: PCI SATA controllers on embedded, no-BIOS targets

[Jeff Garzik]

Kevin Hilman wrote:
> I've now been using a patched sata_sil driver for a while to support PCI
> IO space on my embedded ARM target.  Do you have any plans of pushing
> support for this upstream?

MMIO doesn't work at all?

I'm a bit reluctant to push this into mainline, particularly when I feel 
that the sata_sil driver could still be updated to use only 32-bit MMIO 
transactions without much problem.

	Jeff

Re: PCI SATA controllers on embedded, no-BIOS targets

[Tejun Heo]

Jeff Garzik wrote:
> Kevin Hilman wrote:
>> I've now been using a patched sata_sil driver for a while to support PCI
>> IO space on my embedded ARM target.  Do you have any plans of pushing
>> support for this upstream?
> 
> MMIO doesn't work at all?
> 
> I'm a bit reluctant to push this into mainline, particularly when I feel 
> that the sata_sil driver could still be updated to use only 32-bit MMIO 
> transactions without much problem.

Hello, Kevin, Jeff.

IIRC, Kevin's platform can't do any MMIO.  Also, although sata_sil can 
be made to use 32-bit address space exclusively, I think having PIO 
access in the meantime can be helpful to many newer ATI mips platforms 
out there.  Please note that w/ ioread/write change, the modified code 
is isolated into init_one(), so the added complexity is small.

Thanks.

-- 
tejun

Re: PCI SATA controllers on embedded, no-BIOS targets

[Jeff Garzik]

Tejun Heo wrote:
> IIRC, Kevin's platform can't do any MMIO.  Also, although sata_sil can 
> be made to use 32-bit address space exclusively, I think having PIO 
> access in the meantime can be helpful to many newer ATI mips platforms 
> out there.  Please note that w/ ioread/write change, the modified code 
> is isolated into init_one(), so the added complexity is small.

Having PIO but not MMIO is _highly_ irregular, especially for non-x86 
platforms.  MMIO is much more common because it is easier to implement 
in hardware than PIO.

As an aside:  We should add a 32-bit variant of ->data_xfer hooks, and 
use where appropriate.

	Jeff

Re: PCI SATA controllers on embedded, no-BIOS targets

[Kevin Hilman]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Kevin Hilman wrote:
>>> I've now been using a patched sata_sil driver for a while to support PCI
>>> IO space on my embedded ARM target.  Do you have any plans of pushing
>>> support for this upstream?
>>
>> MMIO doesn't work at all?
>>
>> I'm a bit reluctant to push this into mainline, particularly when I
>> feel that the sata_sil driver could still be updated to use only
>> 32-bit MMIO transactions without much problem.
> 
> Hello, Kevin, Jeff.
> 
> IIRC, Kevin's platform can't do any MMIO.  

Actually, this platform (XScale IXP425, big-endian) can do MMIO.  I have
an e100 PCI card on this board where the driver is using MMIO.  I also
have a Promise Ultra133 PCI card, but not sure if that driver is using
memory space or IO space.

Kevin

Re: PCI SATA controllers on embedded, no-BIOS targets

[Sergei Shtylyov]

Hello.

Kevin Hilman wrote:

>>>>I've now been using a patched sata_sil driver for a while to support PCI
>>>>IO space on my embedded ARM target.  Do you have any plans of pushing
>>>>support for this upstream?

>>>MMIO doesn't work at all?

>>>I'm a bit reluctant to push this into mainline, particularly when I
>>>feel that the sata_sil driver could still be updated to use only
>>>32-bit MMIO transactions without much problem.

>>Hello, Kevin, Jeff.

>>IIRC, Kevin's platform can't do any MMIO.  

> Actually, this platform (XScale IXP425, big-endian) can do MMIO.  I have
> an e100 PCI card on this board where the driver is using MMIO.  I also
> have a Promise Ultra133 PCI card, but not sure if that driver is using
> memory space or IO space.

    The legacy driver uses strictly I/O space; libata one uses MMIO but I 
guess you haven't tried that one...

WBR, Sergei