| Message ID | m33a4nfvva.fsf@intrepid.localdomain |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
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
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").
> 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
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).
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
> 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
> 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
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
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
--- 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);