Patchwork SATA_SIL on IXP425 workaround

login
register
mail settings
Submitter Krzysztof Halasa
Date Nov. 9, 2009, 5:31 p.m.
Message ID <m33a4nfvva.fsf@intrepid.localdomain>
Download mbox | patch
Permalink /patch/38014/
State Not Applicable
Delegated to: David Miller
Headers show

Comments

Krzysztof Halasa - Nov. 9, 2009, 5:31 p.m.
I'm trying to add a workaround for IXP4xx CPUs to SATA SIL driver. The
problem is that IXP4xx CPUs (Intel's XScale (ARM) network-oriented
processors) are unable to perform 8 and 16-bit read from PCI MMIO, they
can only do a full 32-bit readl(); SIL chips respond to that with PCI
abort. The workaround is to use 8 and 16-bit regular IO reads (inb/inw)
instead (MMIO write is not a problem).

For SIL3x12 the workaround is simple (attached) and it works on my 3512.
I'm not sure about 3114 (the 4-port chip) - the PIO BARs have TF, CTL
and BWDMA registers which are common to channels 0 and 2, and (the other
set) to channels 1 and 3. Channel selection is done with bit 4 of
device/head TF register, this is similar (same?) as PATA master/slave.
Does that mean that I can simply treat channel 0 as PRI master, ch#2 as
PRI slave, ch#1 as SEC master and ch#3 as SEC slave, and the SFF code
will select the right device correctly? Does it need additional code?
I don't have anything based on 3114.

Note: the large PRD is not a problem here, the transfer can be started
by MMIO write. Only reads are an issue.
Bartlomiej Zolnierkiewicz - Jan. 14, 2010, 3:59 p.m.
On Monday 09 November 2009 06:31:21 pm Krzysztof Halasa wrote:
> I'm trying to add a workaround for IXP4xx CPUs to SATA SIL driver. The
> problem is that IXP4xx CPUs (Intel's XScale (ARM) network-oriented
> processors) are unable to perform 8 and 16-bit read from PCI MMIO, they
> can only do a full 32-bit readl(); SIL chips respond to that with PCI
> abort. The workaround is to use 8 and 16-bit regular IO reads (inb/inw)
> instead (MMIO write is not a problem).
> 
> For SIL3x12 the workaround is simple (attached) and it works on my 3512.
> I'm not sure about 3114 (the 4-port chip) - the PIO BARs have TF, CTL
> and BWDMA registers which are common to channels 0 and 2, and (the other
> set) to channels 1 and 3. Channel selection is done with bit 4 of
> device/head TF register, this is similar (same?) as PATA master/slave.
> Does that mean that I can simply treat channel 0 as PRI master, ch#2 as
> PRI slave, ch#1 as SEC master and ch#3 as SEC slave, and the SFF code
> will select the right device correctly? Does it need additional code?
> I don't have anything based on 3114.
> 
> Note: the large PRD is not a problem here, the transfer can be started
> by MMIO write. Only reads are an issue.

FWIW your patch is now in my atang tree (I'm aware that Jeff is working
on generic solution but in the meantime this non-intrusive patch allows
sata_sil to work on IXP425).

> --- a/drivers/ata/sata_sil.c
> +++ b/drivers/ata/sata_sil.c
> @@ -757,7 +757,12 @@ static int sil_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  	if (rc)
>  		return rc;
>  
> +#ifdef CONFIG_ARCH_IXP4XX
> +	/* We need all 6 regions on IXP4xx */
> +	rc = pcim_iomap_regions(pdev, 0x3F, DRV_NAME);
> +#else
>  	rc = pcim_iomap_regions(pdev, 1 << SIL_MMIO_BAR, DRV_NAME);
> +#endif
>  	if (rc == -EBUSY)
>  		pcim_pin_device(pdev);
>  	if (rc)
> @@ -777,10 +782,18 @@ static int sil_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  		struct ata_port *ap = host->ports[i];
>  		struct ata_ioports *ioaddr = &ap->ioaddr;
>  
> +#ifdef CONFIG_ARCH_IXP4XX
> +		/* IXP4xx CPUs can't perform 8 and 16-bit MMIO reads,
> +		   use normal IO from/to regions 0-5 instead */
> +		ioaddr->cmd_addr = host->iomap[i * 2];
> +		ioaddr->altstatus_addr = host->iomap[1 + i * 2] + 2;
> +		ioaddr->bmdma_addr = host->iomap[4] + sil_port[i].bmdma;
> +#else
>  		ioaddr->cmd_addr = mmio_base + sil_port[i].tf;
> -		ioaddr->altstatus_addr =
> -		ioaddr->ctl_addr = mmio_base + sil_port[i].ctl;
> +		ioaddr->altstatus_addr = mmio_base + sil_port[i].ctl;
>  		ioaddr->bmdma_addr = mmio_base + sil_port[i].bmdma;
> +#endif
> +		ioaddr->ctl_addr = mmio_base + sil_port[i].ctl;
>  		ioaddr->scr_addr = mmio_base + sil_port[i].scr;
>  		ata_sff_std_ports(ioaddr);

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Halasa - Jan. 14, 2010, 6:08 p.m.
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> writes:

> FWIW your patch is now in my atang tree (I'm aware that Jeff is working
> on generic solution but in the meantime this non-intrusive patch allows
> sata_sil to work on IXP425).

Thanks. BTW I could help with the "general solution", but I wonder if
what we need is simply adding those other ARM archs to IXP4xx (through
Kconfig)? If they have the same problem, namely inability to do
readb/readw only, while being able to write[bwl] and all kinds of non-MM
I/O.

writeb() is important since it starts the "large PRD" transfers (it has
to use MMIO BAR to be "large").
Alan Cox - Jan. 14, 2010, 7:22 p.m.
> FWIW your patch is now in my atang tree (I'm aware that Jeff is working
> on generic solution but in the meantime this non-intrusive patch allows
> sata_sil to work on IXP425).

I think this is the wrong place. If your platform can't do MMIO properly
then the platform pci_iomap or pci quirk code should do the needed
cleaning up, not put turds into the drivers. Why not just quirk it on your
specific platform and clear the MMIO mapping.

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Krzysztof Halasa - Jan. 14, 2010, 8:12 p.m.
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> I think this is the wrong place. If your platform can't do MMIO properly
> then the platform pci_iomap or pci quirk code should do the needed
> cleaning up, not put turds into the drivers. Why not just quirk it on your
> specific platform and clear the MMIO mapping.

We need to use the MMIO BAR at least for starting DMA transfers, the
I/O ones are 64KB-limited. We can't just use read[bw] if reading all
32 bits has side effects.

Most of the time there are no problems with MMIO on IXP4xx as modern
devices usually use 32-bit registers anyway, or at least they have no
problem with read[bw] always driving all four PCI byte enable lines
(write[bw] doesn't have this issue).
Bartlomiej Zolnierkiewicz - Jan. 14, 2010, 8:29 p.m.
On Thursday 14 January 2010 08:22:10 pm Alan Cox wrote:
> > FWIW your patch is now in my atang tree (I'm aware that Jeff is working
> > on generic solution but in the meantime this non-intrusive patch allows
> > sata_sil to work on IXP425).
> 
> I think this is the wrong place. If your platform can't do MMIO properly
> then the platform pci_iomap or pci quirk code should do the needed
> cleaning up, not put turds into the drivers. Why not just quirk it on your
> specific platform and clear the MMIO mapping.

I think that you misinterpreted the issue -- according to Krzysztof MMIO
works just fine, only 8/16-bit MMIO reads are a problem (please note that
using mixed PIO/MMIO access is still a win over pure PIO access and also
that sata_sil doesn't support pure non-MMIO operations currently)..

However if it gets fixed in the upstream kernel in some other way I'll
simply drop the patch during the next re-base of my tree (I just collect
ATA stuff that looks useful/interesting to me and which otherwise may
become lost)..

--
Bartlomiej Zolnierkiewicz
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alan Cox - Jan. 14, 2010, 9 p.m.
> I think that you misinterpreted the issue -- according to Krzysztof MMIO
> works just fine, only 8/16-bit MMIO reads are a problem (please note that
> using mixed PIO/MMIO access is still a win over pure PIO access and also
> that sata_sil doesn't support pure non-MMIO operations currently)..

Have we got timing measurements to prove that ?
> 
> However if it gets fixed in the upstream kernel in some other way I'll
> simply drop the patch during the next re-base of my tree (I just collect
> ATA stuff that looks useful/interesting to me and which otherwise may
> become lost)..

And that's a good thing. The question was aimed at Krzysztof. Really we
need to keep platform specific weirdness out of core drivers or the
rapidly turn into a mess.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Alan Cox - Jan. 14, 2010, 9:05 p.m.
> We need to use the MMIO BAR at least for starting DMA transfers, the
> I/O ones are 64KB-limited. We can't just use read[bw] if reading all
> 32 bits has side effects.

Last time I instrumented this on x86 we never issued a > 64K linear block
in our s/g lists. In fact we went for years before anyone noticed we had
a bug with CS5530 and a couple of other chips that mishandled 64K segment
sizes, and that was only finally noticed in a very specific and weird
circumstance.

> Most of the time there are no problems with MMIO on IXP4xx as modern
> devices usually use 32-bit registers anyway, or at least they have no
> problem with read[bw] always driving all four PCI byte enable lines
> (write[bw] doesn't have this issue).

Fair enough

--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Robert Hancock - Jan. 16, 2010, 5:03 a.m.
On 01/14/2010 03:05 PM, Alan Cox wrote:
>> We need to use the MMIO BAR at least for starting DMA transfers, the
>> I/O ones are 64KB-limited. We can't just use read[bw] if reading all
>> 32 bits has side effects.
>
> Last time I instrumented this on x86 we never issued a>  64K linear block
> in our s/g lists. In fact we went for years before anyone noticed we had
> a bug with CS5530 and a couple of other chips that mishandled 64K segment
> sizes, and that was only finally noticed in a very specific and weird
> circumstance.

Having a block over 64KB may be rare, but the other thing that the large 
block transfer feature does is remove the restriction on a block 
crossing a 64KB boundary, which based on the experiments I did when I 
worked on adding the feature, does happen fairly commonly if the driver 
allows it.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jeff Garzik - Jan. 21, 2010, 5 a.m.
On 01/14/2010 04:00 PM, Alan Cox wrote:
>> I think that you misinterpreted the issue -- according to Krzysztof MMIO
>> works just fine, only 8/16-bit MMIO reads are a problem (please note that
>> using mixed PIO/MMIO access is still a win over pure PIO access and also
>> that sata_sil doesn't support pure non-MMIO operations currently)..
>
> Have we got timing measurements to prove that ?
>>
>> However if it gets fixed in the upstream kernel in some other way I'll
>> simply drop the patch during the next re-base of my tree (I just collect
>> ATA stuff that looks useful/interesting to me and which otherwise may
>> become lost)..
>
> And that's a good thing. The question was aimed at Krzysztof. Really we
> need to keep platform specific weirdness out of core drivers or the
> rapidly turn into a mess.

The lack of 8-/16-byte MMIO access is unfortunately not limited to 
Krzysztof's platform.  Other people have reported the same problem 
specifically with sata_sil (see the archives).

If the driver cannot be converted to all-32-bit accesses, we will need 
to do something like Krzysztof's patch.

	Jeff




--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -757,7 +757,12 @@  static int sil_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 	if (rc)
 		return rc;
 
+#ifdef CONFIG_ARCH_IXP4XX
+	/* We need all 6 regions on IXP4xx */
+	rc = pcim_iomap_regions(pdev, 0x3F, DRV_NAME);
+#else
 	rc = pcim_iomap_regions(pdev, 1 << SIL_MMIO_BAR, DRV_NAME);
+#endif
 	if (rc == -EBUSY)
 		pcim_pin_device(pdev);
 	if (rc)
@@ -777,10 +782,18 @@  static int sil_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 		struct ata_port *ap = host->ports[i];
 		struct ata_ioports *ioaddr = &ap->ioaddr;
 
+#ifdef CONFIG_ARCH_IXP4XX
+		/* IXP4xx CPUs can't perform 8 and 16-bit MMIO reads,
+		   use normal IO from/to regions 0-5 instead */
+		ioaddr->cmd_addr = host->iomap[i * 2];
+		ioaddr->altstatus_addr = host->iomap[1 + i * 2] + 2;
+		ioaddr->bmdma_addr = host->iomap[4] + sil_port[i].bmdma;
+#else
 		ioaddr->cmd_addr = mmio_base + sil_port[i].tf;
-		ioaddr->altstatus_addr =
-		ioaddr->ctl_addr = mmio_base + sil_port[i].ctl;
+		ioaddr->altstatus_addr = mmio_base + sil_port[i].ctl;
 		ioaddr->bmdma_addr = mmio_base + sil_port[i].bmdma;
+#endif
+		ioaddr->ctl_addr = mmio_base + sil_port[i].ctl;
 		ioaddr->scr_addr = mmio_base + sil_port[i].scr;
 		ata_sff_std_ports(ioaddr);