linux-toradex.git/include/asm-powerpc/atomic.h, branch v2.6.23.3

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

[PATCH] mutex subsystem, add atomic_xchg() to all arches

2006-01-09T23:59:17+00:00

add atomic_xchg() to all the architectures. Needed by the new mutex code.

Signed-off-by: Ingo Molnar 
Signed-off-by: Arjan van de Ven

[PATCH] atomic_long_t & include/asm-generic/atomic.h V2

2006-01-06T16:33:29+00:00

Several counters already have the need to use 64 atomic variables on 64 bit
platforms (see mm_counter_t in sched.h).  We have to do ugly ifdefs to fall
back to 32 bit atomic on 32 bit platforms.

The VM statistics patch that I am working on will also make more extensive
use of atomic64.

This patch introduces a new type atomic_long_t by providing definitions in
asm-generic/atomic.h that works similar to the c "long" type.  Its 32 bits
on 32 bit platforms and 64 bits on 64 bit platforms.

Also cleans up the determination of the mm_counter_t in sched.h.

Signed-off-by: Christoph Lameter 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds