Re: question on memory barrier

[moreau francis]

--- Andy Isaacson <adi@xxxxxxxxxxxxx> a écrit :
> 
> Did you *read* the post?
> 
> # The _only_ acceptable use of "volatile" is basically:
> # 
> # - in _code_ (not data structures), where we might mark a place as making
> #   a special type of access. For example, in the PCI MMIO read functions,
> #   rather than use inline assembly to force the particular access (which
> #   would work equally well), we can force the pointer to a volatile type.
> 
> That's *exactly* what the writel you quote above does!

OK but he speaks about special type of access, no ordering constraint.
I don't think that MIPS cpu reorder memory access, but gcc can ! And I
don't think that the use of 'volatile' can prevent it to do that.


> To return to the point directly at hand - on MIPS architectures to date,
> simply doing your memory access through a "volatile u32 *" is sufficient
> to ensure that the IO hits the bus (assuming that your pointer points to
> kseg1, not kseg0, or is otherwise uncached), because 'volatile' forces
> gcc to generate a "sw" for each store, and all MIPS so far have been
> designed so that multiple uncached writes to mmio locations do generate
> multiple bus transactions.

ok thanks for this, but once again, there's no ordering constraint garantuee.

> 
> I'm not an architect, but I think it would be possible to build a MIPS
> where this was not the case, and require additional contortions from
> users.  Such a MIPS would suck to program and would probably fail in the
> marketplace, and there's no compelling benefit to doing so; ergo, I
> would expect "volatile" to continue to be sufficient on MIPS.
> 

I hope so...It's hard to find out an answer to such questions (maybe
it's the case only for MIPS arch) although it's an important point.

Thanks.
             Francis


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/