PCI SATA controllers on embedded, no-BIOS targets

DISCUSSION Kevin Hilman 4 participants 17 messages Aug 22, 2006 – Sep 8, 2006

Subsystems (2)

SCSI libata

lore

Share & tools

lore

Kevin Hilman

author

2006-08-22 16:37 UTC #0 lore raw

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

Tejun Heo

2006-08-22 16:41 UTC #1 lore raw

Quoted 5 lines · 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.

sil3112 works fine w/o any BIOS initialization.

Signature · 1 line

tejun

Kevin Hilman

author

2006-08-22 16:52 UTC #2 lore raw

Quoted 9 lines · Tejun Heo

Quoted 5 lines · 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.
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

Tejun Heo

2006-08-22 17:27 UTC #3 lore raw

Quoted 8 lines · Kevin Hilman

Quoted 7 lines · Tejun Heo
Quoted 5 lines · 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.

Quoted 7 lines

Quoted 2 lines
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.

Signature · 1 line

tejun

Tejun Heo

2006-08-22 17:31 UTC #4 lore raw

Quoted 9 lines · Tejun Heo

Quoted 8 lines · Kevin Hilman
Quoted 7 lines · Tejun Heo
Quoted 5 lines · 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.

Quoted 8 lines

Quoted 6 lines
Quoted 2 lines
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.

Signature · 1 line

tejun

Kevin Hilman

author

2006-08-22 17:37 UTC #5 lore raw

Quoted 10 lines · Tejun Heo

Quoted 9 lines · Tejun Heo
Quoted 8 lines · Kevin Hilman
Quoted 7 lines · Tejun Heo
Quoted 5 lines · 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.

Quoted 8 lines

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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.

Quoted 1 line

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

Tejun Heo

2006-08-22 18:01 UTC #6 lore raw

Quoted 7 lines · Kevin Hilman

Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 1 line
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?

Quoted 1 line

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.

Quoted 1 line

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.

Signature · 1 line

tejun

drivers/scsi/sata_sil.c +40 ~~-28~~

Index: work1/drivers/scsi/sata_sil.c
===================================================================
@@ -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,

Tejun Heo

2006-08-22 18:02 UTC #7 lore raw

Quoted 11 lines · Tejun Heo

Quoted 7 lines · Kevin Hilman
Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 1 line
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?

Quoted 7 lines

Quoted 1 line
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.
Quoted 1 line
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/

Signature · 1 line

tejun

Kevin Hilman

author

2006-08-22 21:58 UTC #8 lore raw

In reply to Tejun Heo

Quoted 7 lines · Tejun Heo

Quoted 6 lines · Kevin Hilman
Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 1 line
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.

Quoted 7 lines

Quoted 1 line
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?
Quoted 1 line
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.

Quoted 3 lines

Quoted 1 line
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

drivers/scsi/sata_sil.c +31 -9

Index: 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,

Tejun Heo

2006-08-23 03:25 UTC #9 lore raw

Quoted 16 lines · Kevin Hilman

Quoted 7 lines · Tejun Heo
Quoted 6 lines · Kevin Hilman
Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 1 line
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.
Quoted 7 lines
Quoted 1 line
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?
Quoted 1 line
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.

Quoted 8 lines

yes, I mean using PCI IO address space.
Quoted 3 lines
Quoted 1 line
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.

Signature · 1 line

tejun

Tejun Heo

2006-08-23 03:53 UTC #10 lore raw

Quoted 19 lines · Tejun Heo

Quoted 18 lines · Kevin Hilman
Quoted 7 lines · Tejun Heo
Quoted 6 lines · Kevin Hilman
Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 1 line
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.
Quoted 7 lines
Quoted 1 line
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?
Quoted 1 line
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.

Quoted 7 lines

Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.

Signature · 1 line

tejun

Kevin Hilman

author

2006-09-07 23:05 UTC #11 lore raw

In reply to Tejun Heo

Quoted 35 lines · Tejun Heo

Quoted 34 lines · Kevin Hilman
Quoted 14 lines · Tejun Heo
Quoted 4 lines · Kevin Hilman
Quoted 1 line
Quoted 1 line
I've personally seen it working on XScale and ATI's mips.
OK, that's good to know.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 8 lines
So, that one can't do byte-aligned mmio either?
Quoted 3 lines
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.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 8 lines

Quoted 5 lines
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

Jeff Garzik

2006-09-08 01:46 UTC #12 lore raw

Quoted 3 lines · Kevin Hilman

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

Tejun Heo

2006-09-08 07:27 UTC #13 lore raw

Quoted 8 lines · Jeff Garzik

Quoted 3 lines · Kevin Hilman
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.

Signature · 1 line

tejun

Jeff Garzik

2006-09-08 12:00 UTC #14 lore raw

Quoted 1 line · Tejun Heo

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

Kevin Hilman

author

2006-09-08 16:29 UTC #15 lore raw

In reply to Tejun Heo

Quoted 8 lines · Tejun Heo

Quoted 7 lines · Jeff Garzik
Quoted 3 lines · Kevin Hilman
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?

Quoted 7 lines

Quoted 3 lines
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

Sergei Shtylyov

2006-09-08 16:38 UTC #16 lore raw

Hello.

Quoted 10 lines · Kevin Hilman

Quoted 9 lines
Quoted 9 lines
Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
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