aboutsummaryrefslogtreecommitdiffstats
path: root/include/asm-m32r/atomic.h
Commit message (Collapse)AuthorAge
* Don't include linux/config.h from anywhere else in include/David Woodhouse2006-04-26
| | | | Signed-off-by: David Woodhouse <dwmw2@infradead.org>
* [PATCH] mutex subsystem, add atomic_xchg() to all archesIngo Molnar2006-01-09
| | | | | | | add atomic_xchg() to all the architectures. Needed by the new mutex code. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Arjan van de Ven <arjan@infradead.org>
* [PATCH] atomic_long_t & include/asm-generic/atomic.h V2Christoph Lameter2006-01-06
| | | | | | | | | | | | | | | | | | | 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 <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] m32r: Introduce atomic_cmpxchg and atomic_inc_not_zero operationsHirokazu Takata2005-11-28
| | | | | | | | | Introduce atomic_cmpxchg and atomic_inc_not_zero operations for m32r. Signed-off-by: Hayato Fujiwara <fujiwara@linux-m32r.org> Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-16
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!