SATA_SIL on IXP425 workaround
in [Kernel]
|
Prev: [PATCH] sparc: leds_resource.end assigned to itself in clock_board_probe()
Next: sparc: leds_resource.end assigned to itself in clock_board_probe()
From: Alan Cox on 14 Jan 2010 16:00 > 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-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 14 Jan 2010 16:10 > 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-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: Robert Hancock on 16 Jan 2010 00:10 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-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: Jeff Garzik on 21 Jan 2010 00:00 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. Jeff
From: Jeff Garzik on 21 Jan 2010 00:10
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-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/ |