Ben,
Ok!
So what do I add to the aic7xxx.c driver to confirm this idea?
Mike
On Tue, 8 Feb 2000, Benjamin Herrenschmidt wrote:
> On Mon, Feb 7, 2000, M Sweger <mikesw@whiterose.net> wrote:
>
> > aic_outb(p, sxfrctl12, SXFRCTL1);
> > write_brdctl(p,brddat);
> > printk(KERN_INFO "works when this message is here");
> > release_seeprom(p);
>
> I'm wondering if this could be a problem with PCI write posting.
> Basically, when you write to PCI, you have no guarantee that the write
> actually ended up to the card unless you do a read from the same bus
> path. It's perfectly legal for PCI bridges to do write posting (keep the
> value in a buffer and terminate the write cycle on the CPU side) while
> asynchronously writing to the card.
> If for any reason there's some bus activity going on at this point, the
> write can be delayed, or simply the bridge may wait for another data to
> do store gathering until an internal timeout expires.
>
> I've been biten by this on another driver, where the udelay after the
> write was almost useless because of that. If you have some timing
> critical constraints between two writes to the card, just make sure you
> do a read _before_ doing the delay & the second write.
>
> I've seen the Adapted driver doing weird things at bus probe time on a
> powermac here when enabling store gathering on the PCI controller. I've
> disabled this feature of the controller on PowerMac kernels for this
> reason (and another problem that I'm currently fixing) but this could be
> the exact same problem you are facing. This powermac has 2 cascaded
> bridges, so when Store Gathering is enabled, the latency before the write
> is actually done on the card can be quite high.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:13 EST