linux.git/include/asm-powerpc/atomic.h, branch master

powerpc: Move include files to arch/powerpc/include/asm

2008-08-04T02:02:00+00:00

from include/asm-powerpc.  This is the result of a

mkdir arch/powerpc/include/asm
git mv include/asm-powerpc/* arch/powerpc/include/asm

Followed by a few documentation/comment fixups and a couple of places
where  was being used explicitly.  Of the latter only
one was outside the arch code and it is a driver only built for powerpc.

Signed-off-by: Stephen Rothwell 
Signed-off-by: Paul Mackerras

[POWERPC] Implement atomic{, 64}_{read, write}() without volatile

2007-08-17T01:01:58+00:00

Instead, use asm() like all other atomic operations already do.

Also use inline functions instead of macros; this actually
improves code generation (some code becomes a little smaller,
probably because of improved alias information -- just a few
hundred bytes total on a default kernel build, nothing shocking).

Signed-off-by: Segher Boessenkool 
Signed-off-by: Paul Mackerras

atomic.h: atomic_add_unless as inline. Remove system.h atomic.h circular dependency

2007-05-08T18:15:20+00:00

atomic_add_unless as inline. Remove system.h atomic.h circular dependency.
I agree (with Andi Kleen) this typeof is not needed and more error
prone. All the original atomic.h code that uses cmpxchg (which includes
the atomic_add_unless) uses defines instead of inline functions,
probably to circumvent a circular dependency between system.h and
atomic.h on powerpc (which my patch addresses). Therefore, it makes
sense to use inline functions that will provide type checking.

atomic_add_unless as inline. Remove system.h atomic.h circular dependency.
Digging into the FRV architecture shows me that it is also affected by
such a circular dependency. Here is the diff applying this against the
rest of my atomic.h patches.

It applies over the atomic.h standardization patches.

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

atomic.h: add atomic64 cmpxchg, xchg and add_unless to powerpc

2007-05-08T18:15:19+00:00

[akpm@linux-foundation.org: build fixes]
Signed-off-by: Mathieu Desnoyers 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[POWERPC] atomic.h: Add atomic64 cmpxchg, xchg and add_unless to powerpc

2007-02-16T03:00:20+00:00

atomic.h : Add atomic64 cmpxchg, xchg and add_unless to powerpc

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Paul Mackerras

[POWERPC] atomic_dec_if_positive sign extension fix

2007-01-22T10:27:36+00:00

On 64-bit machines, if an atomic counter is explicitly set to a
negative value, the atomic_dec_if_positive function will decrement and
store the next smallest value in the atomic counter, contrary to its
intended operation.

The comparison to determine if the decrement will make the result
negative was done by the "addic." instruction, which operates on a
64-bit value, namely the zero-extended word loaded from the atomic
variable.  This patch uses an explicit word compare (cmpwi) and
changes the addic. to an addi (also changing "=&r" to "=&b" so that r0
isn't used, and addi doesn't become li).

This also fixes a bug for both 32-bit and 64-bit in that previously
0x80000000 was considered positive, since the result after
decrementing is positive.  Now it is considered negative.

Also, I clarify the return value in the comments just to make it clear
that the value returned is always the decremented value, even if that
value is not stored back to the atomic counter.

Signed-off-by: Robert Jennings 
Signed-off-by: Paul Mackerras

power: improve inline asm memory constraints

2006-07-08T22:00:28+00:00

Use "+m" rather than a combination of "=m" and "m" for improved
clarity and consistency.

Signed-off-by: Linus Torvalds

[PATCH] powerpc: native atomic_add_unless

2006-02-24T03:06:02+00:00

Do atomic_add_unless natively instead of using cmpxchg.
Improved register allocation idea from Joel Schopp.

Signed-off-by: Nick Piggin 
Signed-off-by: Paul Mackerras

[PATCH] powerpc: reformat atomic_add_unless

2006-01-13T10:18:54+00:00

It makes my eyes hurt.

Signed-off-by: Anton Blanchard 
Signed-off-by: Paul Mackerras

[PATCH] powerpc: use lwsync in atomics, bitops, lock functions

2006-01-13T10:18:50+00:00

eieio is only a store - store ordering. When used to order an unlock
operation loads may leak out of the critical region. This is potentially
buggy, one example is if a user wants to atomically read a couple of
values.

We can solve this with an lwsync which orders everything except store - load.

I removed the (now unused) EIEIO_ON_SMP macros and the c versions
isync_on_smp and eieio_on_smp now we dont use them. I also removed some
old comments that were used to identify inline spinlocks in assembly,
they dont make sense now our locks are out of line.

Another interesting thing was that read_unlock was using an eieio even
though the rest of the spinlock code had already been converted to
use lwsync.

Signed-off-by: Anton Blanchard 
Signed-off-by: Paul Mackerras