[RFT] [SPARC] Emulate cmpxchg like parisc

[RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>

---

PS: Anyone have a nice prebuilt i386->sparc{32,64} xcompiler setup
I could snag? Would be nice to testbuild these patches before I send
them out next time.

diff --git a/arch/sparc/lib/atomic32.c b/arch/sparc/lib/atomic32.c
index 559335f..a45caca 100644
--- a/arch/sparc/lib/atomic32.c
+++ b/arch/sparc/lib/atomic32.c
@@ -2,6 +2,7 @@
  * atomic32.c: 32-bit atomic_t implementation
  *
  * Copyright (C) 2004 Keith M Wesolowski
+ * Copyright (C) 2007 Kyle McMartin
  * 
  * Based on asm-parisc/atomic.h Copyright (C) 2000 Philipp Rumpf
  */
@@ -117,3 +118,17 @@ unsigned long ___change_bit(unsigned long *addr, unsigned long mask)
 	return old & mask;
 }
 EXPORT_SYMBOL(___change_bit);
+
+unsigned long __cmpxchg_u32(volatile u32 *ptr, u32 old, u32 new)
+{
+	unsigned long flags;
+	u32 prev;
+
+	spin_lock_irqsave(ATOMIC_HASH(addr), flags);
+	if ((prev = *addr) = old)
+		*addr = new;
+	spin_unlock_irqrestore(ATOMIC_HASH(addr), flags);
+
+	return (unsigned long)prev;
+}
+EXPORT_SYMBOL(__cmpxchg_u32);
diff --git a/include/asm-sparc/atomic.h b/include/asm-sparc/atomic.h
index 731fa56..ac55f6f 100644
--- a/include/asm-sparc/atomic.h
+++ b/include/asm-sparc/atomic.h
@@ -2,6 +2,7 @@
  *
  * Copyright (C) 1996 David S. Miller (davem@caip.rutgers.edu)
  * Copyright (C) 2000 Anton Blanchard (anton@linuxcare.com.au)
+ * Copyright (C) 2007 Kyle McMartin (kyle@parisc-linux.org)
  *
  * Additions by Keith M Wesolowski (wesolows@foobazco.org) based
  * on asm-parisc/atomic.h Copyright (C) 2000 Philipp Rumpf <prumpf@tux.org>.
@@ -15,6 +16,42 @@ typedef struct { volatile int counter; } atomic_t;
 
 #ifdef __KERNEL__
 
+/* Emulate cmpxchg() the same way we emulate atomics,
+ * by hashing the object address and indexing into an array
+ * of spinlocks to get a bit of performance...
+ *
+ * See arch/sparc/lib/atomic32.c for implementation.
+ *
+ * Cribbed from <asm-parisc/atomic.h>
+ */
+#define __HAVE_ARCH_CMPXCHG	1
+
+/* bug catcher for when unsupported size is used - won't link */
+extern void __cmpxchg_called_with_bad_pointer(void);
+/* we only need to support cmpxchg of a u32 on sparc */
+extern unsigned long __cmpxchg_u32(u32 *m, u32 old, u32 new_);
+
+/* don't worry...optimizer will get rid of most of this */
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new_, int size)
+{
+	switch(size) {
+	case 4:
+		return __cmpxchg_u32((u32 *)ptr, (u32)old, (u32)new_);
+	default:
+		__cmpxchg_called_with_bad_pointer();
+		break;
+	}
+	return old;
+}
+
+#define cmpxchg(ptr,o,n) ({						\
+	__typeof__(*(ptr)) _o_ = (o);					\
+	__typeof__(*(ptr)) _n_ = (n);					\
+	(__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_,	\
+			(unsigned long)_n_, sizeof(*(ptr)));		\
+})
+
 #define ATOMIC_INIT(i)  { (i) }
 
 extern int __atomic_add_return(int, atomic_t *);

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

Hi Kyle,

After some minor fixes this builds, and the DRM drivers also
build again. I cannot test this since I do not have a machine with
PCI or these cards.
Removed your name in the comment, as that went out of fashion after
we started using proper versioning systems.

I've got a ppc->sparc32 compiler if that would help...

Thanks,
Martin

	Acked-by: Martin Habets <errandir_news@mph.eclipse.co.uk>

On Fri, May 25, 2007 at 04:11:43PM -0400, Kyle McMartin wrote:
> Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
> 
> ---
> 
> PS: Anyone have a nice prebuilt i386->sparc{32,64} xcompiler setup
> I could snag? Would be nice to testbuild these patches before I send
> them out next time.


Index: 2.6.21_drm/arch/sparc/lib/atomic32.c
=================================--- 2.6.21_drm.orig/arch/sparc/lib/atomic32.c	2007-05-23 19:31:00.000000000 +0100
+++ 2.6.21_drm/arch/sparc/lib/atomic32.c	2007-05-26 01:07:09.000000000 +0100
@@ -117,3 +117,17 @@
 	return old & mask;
 }
 EXPORT_SYMBOL(___change_bit);
+
+unsigned long __cmpxchg_u32(volatile u32 *addr, u32 old, u32 new)
+{
+	unsigned long flags;
+	u32 prev;
+
+	spin_lock_irqsave(ATOMIC_HASH(addr), flags);
+	if ((prev = *addr) = old)
+		*addr = new;
+	spin_unlock_irqrestore(ATOMIC_HASH(addr), flags);
+
+	return (unsigned long)prev;
+}
+EXPORT_SYMBOL(__cmpxchg_u32);
Index: 2.6.21_drm/include/asm-sparc/atomic.h
=================================--- 2.6.21_drm.orig/include/asm-sparc/atomic.h	2007-05-23 19:31:39.000000000 +0100
+++ 2.6.21_drm/include/asm-sparc/atomic.h	2007-05-26 01:06:37.000000000 +0100
@@ -10,11 +10,48 @@
 #ifndef __ARCH_SPARC_ATOMIC__
 #define __ARCH_SPARC_ATOMIC__
 
+#include <linux/types.h>
 
 typedef struct { volatile int counter; } atomic_t;
 
 #ifdef __KERNEL__
 
+/* Emulate cmpxchg() the same way we emulate atomics,
+ * by hashing the object address and indexing into an array
+ * of spinlocks to get a bit of performance...
+ *
+ * See arch/sparc/lib/atomic32.c for implementation.
+ *
+ * Cribbed from <asm-parisc/atomic.h>
+ */
+#define __HAVE_ARCH_CMPXCHG	1
+
+/* bug catcher for when unsupported size is used - won't link */
+extern void __cmpxchg_called_with_bad_pointer(void);
+/* we only need to support cmpxchg of a u32 on sparc */
+extern unsigned long __cmpxchg_u32(volatile u32 *m, u32 old, u32 new_);
+
+/* don't worry...optimizer will get rid of most of this */
+static __inline__ unsigned long
+__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new_, int size)
+{
+	switch(size) {
+	case 4:
+		return __cmpxchg_u32((u32 *)ptr, (u32)old, (u32)new_);
+	default:
+		__cmpxchg_called_with_bad_pointer();
+		break;
+	}
+	return old;
+}
+
+#define cmpxchg(ptr,o,n) ({						\
+	__typeof__(*(ptr)) _o_ = (o);					\
+	__typeof__(*(ptr)) _n_ = (n);					\
+	(__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_,	\
+			(unsigned long)_n_, sizeof(*(ptr)));		\
+})
+
 #define ATOMIC_INIT(i)  { (i) }
 
 extern int __atomic_add_return(int, atomic_t *);

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Sat, 26 May 2007 01:24:40 +0100

> Hi Kyle,
> 
> After some minor fixes this builds, and the DRM drivers also
> build again. I cannot test this since I do not have a machine with
> PCI or these cards.
> Removed your name in the comment, as that went out of fashion after
> we started using proper versioning systems.
> 
> I've got a ppc->sparc32 compiler if that would help...

So how in the world is something like this going to "work" with DRM?
Userland cannot disable interrupts and it can't take the magic lock
the kernel uses to provide mutual exclusion for the emulated
cmpxchg().

All userland can do is not try to use the atomic operations and always
go into the kernel, which defeats the entire point of the cmpxchg().

Unless something %100 inside of the kernel will be the only consumers
of this, I'd recommend not adding it.  You can't let anything part of
a userland API try to make use of it, and DRM definitely falls into
that category.

Sparc 32-bit barely has PCI let alone 3D graphics cards.

If it's a build issue, simply disallow DRM to be turned on for
SPARC32.

Thanks.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Tom "spot" Callaway]

On Fri, 2007-05-25 at 22:00 -0700, David Miller wrote:
> Sparc 32-bit barely has PCI let alone 3D graphics cards.
> 
> If it's a build issue, simply disallow DRM to be turned on for
> SPARC32. 

I was really wondering about this one. I'd assumed DRM was already
conditionalized out for sparc32.

~spot

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

On Fri, May 25, 2007 at 10:00:36PM -0700, David Miller wrote:
> > After some minor fixes this builds, and the DRM drivers also
> > build again. I cannot test this since I do not have a machine with
> > PCI or these cards.
> > Removed your name in the comment, as that went out of fashion after
> > we started using proper versioning systems.
> > 
> > I've got a ppc->sparc32 compiler if that would help...
> 
> So how in the world is something like this going to "work" with DRM?
> Userland cannot disable interrupts and it can't take the magic lock
> the kernel uses to provide mutual exclusion for the emulated
> cmpxchg().
> 

Hi David,

My knowledge of the DRM is weak, but as I understand it, the only time
it is used is by the ioctl handlers, and not by userspace. I've added
Dave Airlie to the CC list, hopefully he can enlighten us as to where
else cmpxchg is used.

> Unless something %100 inside of the kernel will be the only consumers
> of this, I'd recommend not adding it.  You can't let anything part of
> a userland API try to make use of it, and DRM definitely falls into
> that category.
> 

istr there was a contentious thread on linux-arch about using cmpxchg in
generic code a while ago. So it's possible architectures with crappy
atomic support will need some kind of hack like this to even be able to
use generic code in the future.

> Sparc 32-bit barely has PCI let alone 3D graphics cards.
> 
> If it's a build issue, simply disallow DRM to be turned on for
> SPARC32.
> 
> Thanks.
> 

Cheers,
	Kyle

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

On Fri, May 25, 2007 at 10:00:36PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Sat, 26 May 2007 01:24:40 +0100
> 
> > Hi Kyle,
> > 
> > After some minor fixes this builds, and the DRM drivers also
> > build again. I cannot test this since I do not have a machine with
> > PCI or these cards.
> > Removed your name in the comment, as that went out of fashion after
> > we started using proper versioning systems.
> > 
> > I've got a ppc->sparc32 compiler if that would help...
> 
> So how in the world is something like this going to "work" with DRM?

Work? It's not going to work. DRM checks the architecture in
drm_cpu_valid(), and won't run I guess.

> Userland cannot disable interrupts and it can't take the magic lock
> the kernel uses to provide mutual exclusion for the emulated
> cmpxchg().
> 
> All userland can do is not try to use the atomic operations and always
> go into the kernel, which defeats the entire point of the cmpxchg().
> 
> Unless something %100 inside of the kernel will be the only consumers
> of this, I'd recommend not adding it.  You can't let anything part of
> a userland API try to make use of it, and DRM definitely falls into
> that category.
> 
> Sparc 32-bit barely has PCI let alone 3D graphics cards.
> 
> If it's a build issue, simply disallow DRM to be turned on for
> SPARC32.

LOL, that was my initial approach until I saw Kyle's code.
Here's the patch I was preparing for that:
---

The DRM code does not build clean for sparc32 because it depends on
cmpxchg() which is not available. Even if it would build, it would
not run anyways because of the check in drm_cpu_valid().
So the best solution is to remove DRM for sparc32.

Patch against 2.6.21 attached.

Martin

	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
---
Index: 2.6.21_drm/drivers/char/drm/Kconfig
=================================--- 2.6.21_drm.orig/drivers/char/drm/Kconfig	2007-05-23 22:35:32.000000000 +0100
+++ 2.6.21_drm/drivers/char/drm/Kconfig	2007-05-23 22:37:25.000000000 +0100
@@ -6,7 +6,7 @@
 #
 config DRM
 	tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
-	depends on (AGP || AGP=n) && PCI
+	depends on (AGP || AGP=n) && PCI && !SPARC32
 	help
 	  Kernel-level support for the Direct Rendering Infrastructure (DRI)
 	  introduced in XFree86 4.0. If you say Y here, you need to select

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Dave Airlie]

>
> My knowledge of the DRM is weak, but as I understand it, the only time
> it is used is by the ioctl handlers, and not by userspace. I've added
> Dave Airlie to the CC list, hopefully he can enlighten us as to where
> else cmpxchg is used.
>
>> Unless something %100 inside of the kernel will be the only consumers
>> of this, I'd recommend not adding it.  You can't let anything part of
>> a userland API try to make use of it, and DRM definitely falls into
>> that category.
>>
>
> istr there was a contentious thread on linux-arch about using cmpxchg in
> generic code a while ago. So it's possible architectures with crappy
> atomic support will need some kind of hack like this to even be able to
> use generic code in the future.
>
>> Sparc 32-bit barely has PCI let alone 3D graphics cards.
>>

the DRM can use cmpxchg in userspace, to implement DRM_CAS, have a look in 
drm git libdrm/xf86drm.h we appear to have a sparc implementation, this 
gives us fast userspace locking, however if an arch doesn't implement 
DRM_CAS we fallback to the heavyweight in-kernel lock,

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb / ILUG

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Kyle McMartin <kyle@parisc-linux.org>
Date: Sat, 26 May 2007 10:45:09 -0400

> On Fri, May 25, 2007 at 10:00:36PM -0700, David Miller wrote:
> > > After some minor fixes this builds, and the DRM drivers also
> > > build again. I cannot test this since I do not have a machine with
> > > PCI or these cards.
> > > Removed your name in the comment, as that went out of fashion after
> > > we started using proper versioning systems.
> > > 
> > > I've got a ppc->sparc32 compiler if that would help...
> > 
> > So how in the world is something like this going to "work" with DRM?
> > Userland cannot disable interrupts and it can't take the magic lock
> > the kernel uses to provide mutual exclusion for the emulated
> > cmpxchg().
> > 
> 
> Hi David,
> 
> My knowledge of the DRM is weak, but as I understand it, the only time
> it is used is by the ioctl handlers, and not by userspace. I've added
> Dave Airlie to the CC list, hopefully he can enlighten us as to where
> else cmpxchg is used.
> 
> > Unless something %100 inside of the kernel will be the only consumers
> > of this, I'd recommend not adding it.  You can't let anything part of
> > a userland API try to make use of it, and DRM definitely falls into
> > that category.
> > 
> 
> istr there was a contentious thread on linux-arch about using cmpxchg in
> generic code a while ago. So it's possible architectures with crappy
> atomic support will need some kind of hack like this to even be able to
> use generic code in the future.

For purely kernel stuff it's fine, because the lock and the interrupt
disabling will be used consistently by all accesses.

But the words that operate on cmpxchg() in DRM are exported to
userspace, and therefore cannot make use of the locking scheme
that atomically challenged platforms need to make use of in
the kernel.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Sat, 26 May 2007 20:39:09 +0100

> LOL, that was my initial approach until I saw Kyle's code.
> Here's the patch I was preparing for that:

Even better would be to test if the platform has a real CMPXCHG
instruction since sparc32 is not the only platform with this issue.

We can add a KCONFIG variable for that, and not set it on
sparc32 et al.

Alternatively we can have a KCONFIG variable with reversed
logic, like "EMULATED_CMPXCHG" which only the atomically
challenged platforms need to set.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Dave Airlie <airlied@linux.ie>
Date: Sat, 26 May 2007 21:32:10 +0100 (IST)

> the DRM can use cmpxchg in userspace, to implement DRM_CAS, have a look in 
> drm git libdrm/xf86drm.h we appear to have a sparc implementation, this 
> gives us fast userspace locking, however if an arch doesn't implement 
> DRM_CAS we fallback to the heavyweight in-kernel lock,

That instruction only works on sparc64 cpus, which includes
32-bit apps running a system with sparc64 cpus.

That's why I hard-code the opcode in that asm statement of
the DRM sources.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

On Sat, May 26, 2007 at 04:00:56PM -0700, David Miller wrote:
> From: Dave Airlie <airlied@linux.ie>
> Date: Sat, 26 May 2007 21:32:10 +0100 (IST)
> 
> > the DRM can use cmpxchg in userspace, to implement DRM_CAS, have a look in 
> > drm git libdrm/xf86drm.h we appear to have a sparc implementation, this 
> > gives us fast userspace locking, however if an arch doesn't implement 
> > DRM_CAS we fallback to the heavyweight in-kernel lock,
> 
> That instruction only works on sparc64 cpus, which includes
> 32-bit apps running a system with sparc64 cpus.
> 
> That's why I hard-code the opcode in that asm statement of
> the DRM sources.
> 

I don't see what the problem is? If we can't do it in userspace, we fall
back to a heavyweight ioctl lock. This sounds sensible to me.

On parisc we implement userspace CAS with a lightweight syscall on our
gateway page, likely something like this could be implemented if someone
cared on sparc32 as well using a VDSO.

Cheers,
	Kyle

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Kyle McMartin <kyle@parisc-linux.org>
Date: Sat, 26 May 2007 19:41:34 -0400

> I don't see what the problem is? If we can't do it in userspace, we fall
> back to a heavyweight ioctl lock. This sounds sensible to me.
> 
> On parisc we implement userspace CAS with a lightweight syscall on our
> gateway page, likely something like this could be implemented if someone
> cared on sparc32 as well using a VDSO.

Indeed, a special syscall scheme would work on sparc32 too, but very
inefficiently for the case that matters the most.

I don't want to have to take the syscall if the 32-bit app is running
on a sparc64 kernel which has the cmpxchg instructions.

Sure I could do vsyscall pages and all that, but it won't happen any
time soon and penalizing the existing 32-bit userspace by always
taking the system call just for this DRM thing is a non-starter.

What we have right now works for all the systems that actually have
DRM capable cards, and ever will have such cards.

Building DRM on sparc32 is really pointless, there is no graphics
card that will ever be plugged into a sparc32 PCI system that can
support DRM, ever.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

On Sat, May 26, 2007 at 03:59:21PM -0700, David Miller wrote:
> Alternatively we can have a KCONFIG variable with reversed
> logic, like "EMULATED_CMPXCHG" which only the atomically
> challenged platforms need to set.

Like this idea, but if we're not going to build DRM I see no
point adding the cmpxchg emulation to sparc32. Maybe "NOARCH_CMPXCHG"
would be better?

-- 
Martin

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Mon, 28 May 2007 01:07:46 +0100

> On Sat, May 26, 2007 at 03:59:21PM -0700, David Miller wrote:
> > Alternatively we can have a KCONFIG variable with reversed
> > logic, like "EMULATED_CMPXCHG" which only the atomically
> > challenged platforms need to set.
> 
> Like this idea, but if we're not going to build DRM I see no
> point adding the cmpxchg emulation to sparc32. Maybe "NOARCH_CMPXCHG"
> would be better?

It is likely that we are going to have generic users of cmpxchg() in
the kernel in the future (I think the -rt patch set has some which are
hard to get rid of) at which point we'd probably put the emulated
cmpxchg() in there anyways.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

On Sun, May 27, 2007 at 07:49:21PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Mon, 28 May 2007 01:07:46 +0100
> 
> > On Sat, May 26, 2007 at 03:59:21PM -0700, David Miller wrote:
> > > Alternatively we can have a KCONFIG variable with reversed
> > > logic, like "EMULATED_CMPXCHG" which only the atomically
> > > challenged platforms need to set.
> > 
> > Like this idea, but if we're not going to build DRM I see no
> > point adding the cmpxchg emulation to sparc32. Maybe "NOARCH_CMPXCHG"
> > would be better?
> 
> It is likely that we are going to have generic users of cmpxchg() in
> the kernel in the future (I think the -rt patch set has some which are
> hard to get rid of) at which point we'd probably put the emulated
> cmpxchg() in there anyways.
> 

Yeah, David Howells wanted to use cmpxchg in his work struct patch, but
had to not because not everyone implements it.

From what I can tell, very few arches actually have CAS, and others
emulate it with LL/SC type implementations.

Cheers,
	Kyle

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Kyle McMartin <kyle@parisc-linux.org>
Date: Sun, 27 May 2007 23:11:14 -0400

> Yeah, David Howells wanted to use cmpxchg in his work struct patch, but
> had to not because not everyone implements it.
> 
> >From what I can tell, very few arches actually have CAS, and others
> emulate it with LL/SC type implementations.

That's fine, as a LL/SC implementation of cmpxchg() is fully
atomic and would work in concert with a userspace cmpxchg()
implemented with LL/SC.

It's the platforms that lack CAS _and_ some kind of LL/SC
which are problematic.

Sparc32 SMP cpus (sparcv8 sun4m and later) have a 'swap' instruction
but that does not have an inifinite consensus number like CAS and
LL/SC, so it can't be used to implement cmpxchg() (and also the
non-SMP sparc32 chips lack the instruction).

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

On Sun, May 27, 2007 at 07:49:21PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Mon, 28 May 2007 01:07:46 +0100
> 
> > On Sat, May 26, 2007 at 03:59:21PM -0700, David Miller wrote:
> > > Alternatively we can have a KCONFIG variable with reversed
> > > logic, like "EMULATED_CMPXCHG" which only the atomically
> > > challenged platforms need to set.
> > 
> > Like this idea, but if we're not going to build DRM I see no
> > point adding the cmpxchg emulation to sparc32. Maybe "NOARCH_CMPXCHG"
> > would be better?
> 
> It is likely that we are going to have generic users of cmpxchg() in
> the kernel in the future (I think the -rt patch set has some which are
> hard to get rid of) at which point we'd probably put the emulated
> cmpxchg() in there anyways.

Good to see someone has a crystal ball handy. So a patch like like this
to solve the DRM issue? With it DRM can no longer be selected.

---
The DRM code depends on an atomic version of cmpxchg(), which is not
available on sparc32. Since other platforms besides sparc32 have
this issue a KCONFIG option is added for it.

Martin

	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>

Index: 2.6.21_drm/drivers/char/drm/Kconfig
=================================--- 2.6.21_drm.orig/drivers/char/drm/Kconfig	2007-05-26 00:18:45.000000000 +0100
+++ 2.6.21_drm/drivers/char/drm/Kconfig	2007-05-28 23:49:12.000000000 +0100
@@ -6,7 +6,7 @@
 #
 config DRM
 	tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"
-	depends on (AGP || AGP=n) && PCI
+	depends on (AGP || AGP=n) && PCI && !EMULATED_CMPXCHG
 	help
 	  Kernel-level support for the Direct Rendering Infrastructure (DRI)
 	  introduced in XFree86 4.0. If you say Y here, you need to select
Index: 2.6.21_drm/arch/sparc/Kconfig
=================================--- 2.6.21_drm.orig/arch/sparc/Kconfig	2007-05-23 19:31:01.000000000 +0100
+++ 2.6.21_drm/arch/sparc/Kconfig	2007-05-29 00:03:16.000000000 +0100
@@ -178,6 +178,13 @@
 	bool
 	default n
 
+config EMULATED_CMPXCHG
+	bool
+	default y
+	help
+	  Sparc32 does not have a CAS instruction like sparc64. cmpxchg()
+	  is emulated, and therefore it is not completely atomic.
+
 config SUN_PM
 	bool
 	default y

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Tue, 29 May 2007 00:37:01 +0100

> Good to see someone has a crystal ball handy. So a patch like like this
> to solve the DRM issue? With it DRM can no longer be selected.
> 
> ---
> The DRM code depends on an atomic version of cmpxchg(), which is not
> available on sparc32. Since other platforms besides sparc32 have
> this issue a KCONFIG option is added for it.
> 
> Martin
> 
> 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>

This looks great, I've applied Kyle's original patch and this
one, thanks a lot!

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Tue, 29 May 2007 00:37:01 +0100
> 
> > Good to see someone has a crystal ball handy. So a patch like like this
> > to solve the DRM issue? With it DRM can no longer be selected.
> > 
> > ---
> > The DRM code depends on an atomic version of cmpxchg(), which is not
> > available on sparc32. Since other platforms besides sparc32 have
> > this issue a KCONFIG option is added for it.
> > 
> > Martin
> > 
> > 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
> 
> This looks great, I've applied Kyle's original patch and this
> one, thanks a lot!
> 

Thanks David. Yeah, I think adding a Kconfig is the right approach.

Cheers!
	Kyle

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Tue, 29 May 2007 00:37:01 +0100
> 
> > Good to see someone has a crystal ball handy. So a patch like like this
> > to solve the DRM issue? With it DRM can no longer be selected.
> > 
> > ---
> > The DRM code depends on an atomic version of cmpxchg(), which is not
> > available on sparc32. Since other platforms besides sparc32 have
> > this issue a KCONFIG option is added for it.
> > 
> > Martin
> > 
> > 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
> 
> This looks great, I've applied Kyle's original patch and this
> one, thanks a lot!

Ehh, Kyle's original patch did not build. See my initial reply to that
one, which has a version that does build cleanly.

Thanks,
-- 
Martin

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[David Miller]

From: Martin Habets <errandir_news@mph.eclipse.co.uk>
Date: Tue, 29 May 2007 21:30:45 +0100

> On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> > From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > Date: Tue, 29 May 2007 00:37:01 +0100
> > 
> > > Good to see someone has a crystal ball handy. So a patch like like this
> > > to solve the DRM issue? With it DRM can no longer be selected.
> > > 
> > > ---
> > > The DRM code depends on an atomic version of cmpxchg(), which is not
> > > available on sparc32. Since other platforms besides sparc32 have
> > > this issue a KCONFIG option is added for it.
> > > 
> > > Martin
> > > 
> > > 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > 
> > This looks great, I've applied Kyle's original patch and this
> > one, thanks a lot!
> 
> Ehh, Kyle's original patch did not build. See my initial reply to that
> one, which has a version that does build cleanly.

I fixed his version to build and more match the types of the
parisc code when I chekced it in.

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Kyle McMartin]

On Tue, May 29, 2007 at 01:59:31PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Tue, 29 May 2007 21:30:45 +0100
> 
> > On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> > > From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > > Date: Tue, 29 May 2007 00:37:01 +0100
> > > 
> > > > Good to see someone has a crystal ball handy. So a patch like like this
> > > > to solve the DRM issue? With it DRM can no longer be selected.
> > > > 
> > > > ---
> > > > The DRM code depends on an atomic version of cmpxchg(), which is not
> > > > available on sparc32. Since other platforms besides sparc32 have
> > > > this issue a KCONFIG option is added for it.
> > > > 
> > > > Martin
> > > > 
> > > > 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > > 
> > > This looks great, I've applied Kyle's original patch and this
> > > one, thanks a lot!
> > 
> > Ehh, Kyle's original patch did not build. See my initial reply to that
> > one, which has a version that does build cleanly.
> 
> I fixed his version to build and more match the types of the
> parisc code when I chekced it in.
> 

Heh, I was about to do the same to the parisc code as I had cleaned up
in the sparc code... Ah well. :)

Cheers,
	Kyle

Re: [RFT] [SPARC] Emulate cmpxchg like parisc

[Martin Habets]

On Tue, May 29, 2007 at 01:59:31PM -0700, David Miller wrote:
> From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> Date: Tue, 29 May 2007 21:30:45 +0100
> 
> > On Tue, May 29, 2007 at 01:12:33AM -0700, David Miller wrote:
> > > From: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > > Date: Tue, 29 May 2007 00:37:01 +0100
> > > 
> > > > Good to see someone has a crystal ball handy. So a patch like like this
> > > > to solve the DRM issue? With it DRM can no longer be selected.
> > > > 
> > > > ---
> > > > The DRM code depends on an atomic version of cmpxchg(), which is not
> > > > available on sparc32. Since other platforms besides sparc32 have
> > > > this issue a KCONFIG option is added for it.
> > > > 
> > > > Martin
> > > > 
> > > > 	Signed-off-by: Martin Habets <errandir_news@mph.eclipse.co.uk>
> > > 
> > > This looks great, I've applied Kyle's original patch and this
> > > one, thanks a lot!
> > 
> > Ehh, Kyle's original patch did not build. See my initial reply to that
> > one, which has a version that does build cleanly.
> 
> I fixed his version to build and more match the types of the
> parisc code when I chekced it in.

I also got a build error on 'addr' in __cmpxchg_u32(). Changed those
to 'ptr'.
Maybe I've just got an -Wextra-dumb switch on my cc, or you've got
a -Wpsychic :).

-- 
Martin