On Mon, Feb 7, 2000, M Sweger <[EMAIL PROTECTED]> 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-scsi" in
the body of a message to [EMAIL PROTECTED]
