On Tue, Dec 17, 2013 at 01:24:33PM +0100, Thierry Reding wrote: > On Tue, Dec 17, 2013 at 11:51:36AM +0000, Russell King - ARM Linux wrote: > > Same comments here - what memory operations is the wmb() trying to > > serialise? Does this PWM driver somehow end up doing DMA? > > Not that I can see. But if my understanding is correct, not using the > barriers would allow the compiler and CPU to reorder accesses, and by > that cause the register accesses to potentially happen in the wrong > order. The compiler won't reorder them, but the CPU may if it meets certain criteria. The architecture guarantees that accesses to device memory within a (minimum of) 1KB block will be ordered. The ARM ARM is slightly ambiguous in how this is applied - in one place it says that "Accesses must arrive at any particular memory-mapped peripheral or block of memory in program order" and another part it says "The size of a memory mapped peripheral, or a block of memory, is IMPLEMENTATION DEFINED, but is not smaller than 1KByte. Note This implies that the maximum memory-mapped peripheral size for which the architecture guarantees order for all implementations is 1KB." See page A3-148. What this means (to me at least) is that on any SoC, the architecture guarantees that accesses _within_ a 1KB device memory block will always be ordered, but two accesses outside of a 1KB block _to the same device_ is implementation defined whether it is ordered or not. The interesting point here though is that the "note" contradicts the first definition if you have (eg) AMBA Primecell peripherals which are generally 4KB in size, since if the architecture only guarantees 1KB, then accesses _may_ _not_ arrive at one primecell in program order. Hence, the note is a direct contradiction of the first definition. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
