Hi Scott, On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood <scottw...@freescale.com> wrote: > On 02/08/2013 09:11:57 AM, Simon Glass wrote: >> >> These are available on other architectures, so add them on ppc. >> >> Signed-off-by: Simon Glass <s...@chromium.org> >> --- >> Changes in v5: None >> Changes in v4: None >> Changes in v3: None >> Changes in v2: None >> >> arch/powerpc/include/asm/io.h | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h >> index 1f12c29..1bf12f5 100644 >> --- a/arch/powerpc/include/asm/io.h >> +++ b/arch/powerpc/include/asm/io.h >> @@ -317,4 +317,12 @@ static inline phys_addr_t virt_to_phys(void * vaddr) >> #endif >> } >> >> +/* >> + * TODO: The kernel offers some more advanced versions of barriers, it >> might >> + * have some advantages to use them instead of the simple one here. >> + */ >> +#define dmb() __asm__ __volatile__ ("" : : : "memory") >> +#define __iormb() dmb() >> +#define __iowmb() dmb() > > > What is the definition of these? Given that we already have an > architecture-independent barrier(), I assume this is meant to be an actual > hardware barrier rather than a compiler barrier, so this is not a correct > implementation.
They were introduced in ARM in commit 3c0659b5, so I am really just following along with that. Yes the naming doesn't make a lot of sense, but on the other hand I don't think we necessarily want an actual hardware barrier in our writel()s. This at least makes sure that the compiler writes in the right order - perhaps the intent is that that rest is best left to the hardware? Regards, Simon > > -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot