From: Bartlomiej Zolnierkiewicz on
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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on
Bartlomiej Zolnierkiewicz <bzolnier(a)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").
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Cox on
> 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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on
Alan Cox <alan(a)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).
--
Krzysztof Halasa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bartlomiej Zolnierkiewicz on
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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/