Re: SATA_SIL on IXP425 workaround

From: Jeff Garzik
Date: Thu Jan 21 2010 - 01:49:14 EST


On 01/20/2010 11:58 PM, Jeff Garzik wrote:
On 01/14/2010 10:59 AM, Bartlomiej Zolnierkiewicz wrote:
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).

I was asking an open question, is a generic solution possible?

Something like the attached patch might work, due it is completely
untested, and I did not verify that the BMDMA Status register is not
stomped. Also, the additional ioread32() calls in bmdma start/stop are
LIKELY to be unnecessary.

As I suspected, there is a W1C register in there. But it does look possible to do all-32-bit accesses.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/