Re: [PATCH] Fix mmiowb() for MIPS I

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 21, 2007 at 05:46:18PM +0000, Maciej W. Rozycki wrote:

> > diff --git a/include/asm-mips/io.h b/include/asm-mips/io.h
> > index 92ec261..855c304 100644
> > --- a/include/asm-mips/io.h
> > +++ b/include/asm-mips/io.h
> > @@ -502,8 +502,7 @@ BUILDSTRING(q, u64)
> >  #endif
> >  
> >  
> > -/* Depends on MIPS II instruction set */
> > -#define mmiowb() asm volatile ("sync" ::: "memory")
> > +#define mmiowb() __sync()
> >  
> >  static inline void memset_io(volatile void __iomem *addr, unsigned char val, int count)
> >  {
> 
>  That's still not correct -- it should probably be defined like mb() 
> currently is as the write-back buffer may defeat strong ordering (IIRC, 
> the R2020 can do byte merging).  Also the semantics of mmiowb() does not 
> seem to be well specified -- I gather a sequence of:
> 
> 	writeb(mmioreg, val);
> 	mmiowb();
> 	readb(mmioreg);
> 
> should guarantee "val" has reached the register (mmiowb() replacing 
> incorrect mb() used in many places like this), but with either definition 
> of mmiowb() and a MIPS-I-style external write-back buffer it will not 
> work.

Does a read from the same device suffice to provide the necessary flushing
the same way as it does on PCI?

I'm not opposed to allowing platform specific definitions for operations
like mmiowbb() but I think we really should get rid of the special MIPS
iob() operation.

  Ralf


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux