aboutsummaryrefslogtreecommitdiff
path: root/include/asm-alpha/atomic.h
AgeCommit message (Collapse)AuthorFilesLines
2008-08-15alpha: move include/asm-alpha to arch/alpha/include/asmLinus Torvalds1-267/+0
Sam Ravnborg did the build-test that the direct header file move works, I'm just committing it. This is a pure move: mkdir arch/alpha/include git mv include/asm-alpha arch/alpha/include/asm with no other changes. Requested-and-tested-by: Sam Ravnborg <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2008-02-05alpha: atomic_add_return() should return intAndrew Morton1-1/+1
Prevents stuff like drivers/crypto/hifn_795x.c:2443: warning: format '%d' expects type 'int', but argument 4 has type 'long int' drivers/crypto/hifn_795x.c:2443: warning: format '%d' expects type 'int', but argument 4 has type 'long int' (at least). Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-05-08atomic.h: atomic_add_unless as inline. Remove system.h atomic.h circular ↵Mathieu Desnoyers1-28/+31
dependency 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 <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2007-05-08atomic.h: add atomic64 cmpxchg, xchg and add_unless to alphaMathieu Desnoyers1-3/+46
This series mainly adds support for missing 64 bits cmpxchg and 64 bits atomic add unless. Therefore, principally 64 bits architectures are targeted by these patches. It also adds the complete list of atomic operations on the atomic_long type. This patch: atomic.h: add atomic64 cmpxchg, xchg and add_unless to alpha Signed-off-by: Mathieu Desnoyers <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2006-01-09[PATCH] mutex subsystem, add atomic_xchg() to all archesIngo Molnar1-0/+1
add atomic_xchg() to all the architectures. Needed by the new mutex code. Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]>
2006-01-06[PATCH] atomic_long_t & include/asm-generic/atomic.h V2Christoph Lameter1-0/+1
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 <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-11-23[PATCH] mm: fill arch atomic64 gapsHugh Dickins1-2/+5
alpha, sparc64, x86_64 are each missing some primitives from their atomic64 support: fill in the gaps I've noticed by extrapolating asm, follow the groupings in each file. But powerpc and parisc still lack atomic64. Signed-off-by: Hugh Dickins <[email protected]> Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Cc: "David S. Miller" <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Nick Piggin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-11-13[PATCH] atomic: inc_not_zeroNick Piggin1-0/+10
Introduce an atomic_inc_not_zero operation. Make this a special case of atomic_add_unless because lockless pagecache actually wants atomic_inc_not_negativeone due to its offset refcount. Signed-off-by: Nick Piggin <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-11-13[PATCH] atomic: cmpxchgNick Piggin1-0/+2
Introduce an atomic_cmpxchg operation. Signed-off-by: Nick Piggin <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-10-25[PATCH] alpha: atomic dependency fixAndrew Morton1-0/+2
My alpha build is exploding because asm/atomic.h now needs smb_mb(), which is over in the (not included) system.h. I fear what will happen if I include system.h into atomic.h, so let's put the barriers into their own header file. Cc: Richard Henderson <[email protected]> Cc: Ivan Kokshaysky <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-10-22[PATCH] alpha: additional smp barriersIvan Kokshaysky1-4/+8
As stated in Documentation/atomic_ops.txt, atomic functions returning values must have the memory barriers both before and after the operation. Thanks to DaveM for pointing that out. Signed-off-by: Ivan Kokshaysky <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+198
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!