From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 12 Feb 2013 12:50:22 -0600 Subject: [U-Boot] [PATCH v5 01/23] ppc: Add initial memory barrier macros In-Reply-To: (from sjg@chromium.org on Tue Feb 12 12:44:16 2013) References: <1360336339-10703-1-git-send-email-sjg@chromium.org> <1360336339-10703-2-git-send-email-sjg@chromium.org> <1360612347.8517.6@snotra> Message-ID: <1360695022.24612.5@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/12/2013 12:44:16 PM, Simon Glass wrote: > Hi Scott, > > On Mon, Feb 11, 2013 at 11:52 AM, Scott Wood > 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 > >> --- > >> 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. We do have a hardware barrier in writel() on PPC (ignoring the broken never-used little-endian implementation, which should just be removed), and it should stay that way. I do not think we should be introducing anything that looks like a hardware barrier but isn't, unless the semantics of a particular barrier are guaranteed by a particular platform without needing a barrier instruction. And in that case there had better be a document somewhere that explains what the semantics are. > 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? Regardless of what one might think is "best", it isn't left to hardware on many platforms, including PPC. -Scott