Re: SCSI QLA not working on latest *-mm SN2

[Jeremy Higdon <jeremy@sgi.com>]

On Sat, Sep 18, 2004 at 02:25:17AM +0100, Matthew Wilcox wrote:
> On Fri, Sep 17, 2004 at 06:15:10PM -0700, Andrew Vasquez wrote:
> > On Fri, 17 Sep 2004, James Bottomley wrote:
> > > Just to confirm if we absolutely have to do this...the offending reads
> > > to issue the posting flush were to the register you just wrote to to get
> > > the chip to reset.  However, any MMIO read to any region of that card
> > > would also trigger a posted write flush.  Does the chip drop entirely
> > > off the PCI bus during the execution of reset, or could we perhaps issue
> > > an innocuous read to somewhere in PCI configuration space for the card?
> > 
> > I had asked the hardware guy a similar question -- for the soft-reset
> > operation, we'll _not_ be able to issue additional readw()s until '16
> > PCI clocks elapse.'  So, it seems we'll have to settle with the
> > udelay() in this particular instance.
> 
> But the write that starts the reset can be delayed arbitrarily, so we need
> to do *some* kind of read from the device to be know that it got there.
> Can we access config space instead of mmio space?


This is where some sort of generic primitive for flushing posted writes
would be handy.  For any PCI implementation, there will be registers
unrelated to the chip in question that one should be able to read and
which flush the posted write.

On Altix, we have the sn_mmiob()  :-)

A pci_config_read_word() is not quite the same as a readw(), I don't
think, so maybe that would be okay?

jeremy