On Wed, Feb 10, 2010 at 10:04:06PM +1100, Anton Blanchard wrote:
> 
> For performance reasons we are about to change ISYNC_ON_SMP to sometimes be
> lwsync. Now that the macro name doesn't make sense, change it and 
> LWSYNC_ON_SMP
> to better explain what the barriers are doing.
> 
> Signed-off-by: Anton Blanchard <an...@samba.org>
> ---
> 
> Index: powerpc.git/arch/powerpc/include/asm/atomic.h
> ===================================================================
> --- powerpc.git.orig/arch/powerpc/include/asm/atomic.h        2010-02-10 
> 17:12:30.264322204 +1100
> +++ powerpc.git/arch/powerpc/include/asm/atomic.h     2010-02-10 
> 17:13:05.355571902 +1100
> @@ -49,13 +49,13 @@ static __inline__ int atomic_add_return(
>       int t;
>  
>       __asm__ __volatile__(
> -     LWSYNC_ON_SMP
> +     PPC_RELEASE_BARRIER
>  "1:  lwarx   %0,0,%2         # atomic_add_return\n\
>       add     %0,%1,%0\n"
>       PPC405_ERR77(0,%2)
>  "    stwcx.  %0,0,%2 \n\
>       bne-    1b"
> -     ISYNC_ON_SMP
> +     PPC_ACQUIRE_BARRIER

I wonder if this shouldn't be called PPC_ISYNC_ACQUIRE_BARRIER ?

Unlike PPC_RELEASE_BARRIER, it is not an acquire barrier unless it
is used like an isync.

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to