Re: linux-2.5.18: DRM + cmpxchg issues

Re: linux-2.5.18: DRM + cmpxchg issues

[Keith Whitwell]

Adam,

I expect the answer is that we need to dig out the old one.

Previously I don't think the full cmpxchg semantics werere required unless the 
box is smp -- there's no case where atomic operations are required for 
hardware interaction, for example.  ...

Probably this changed with preempt, though, so we need one even on UP boxes...

Keith

Re: linux-2.5.18: DRM + cmpxchg issues

[george anzinger]

Keith Whitwell wrote:
> 
> Adam,
> 
> I expect the answer is that we need to dig out the old one.
> 
> Previously I don't think the full cmpxchg semantics werere required unless the
> box is smp -- there's no case where atomic operations are required for
> hardware interaction, for example.  ...
> 
> Probably this changed with preempt, though, so we need one even on UP boxes...
> 
I can not think of any reason to need a lock or atomic
operation because of preempt.  Even the management of the
preempt on/off flags at most requires memory barriers, even
in SMP boxen.  Do you have an example?
-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

Re: linux-2.5.18: DRM + cmpxchg issues

[Keith Whitwell]

george anzinger wrote:
> Keith Whitwell wrote:
> 
>>Adam,
>>
>>I expect the answer is that we need to dig out the old one.
>>
>>Previously I don't think the full cmpxchg semantics werere required unless the
>>box is smp -- there's no case where atomic operations are required for
>>hardware interaction, for example.  ...
>>
>>Probably this changed with preempt, though, so we need one even on UP boxes...
>>
>>
> I can not think of any reason to need a lock or atomic
> operation because of preempt.  Even the management of the
> preempt on/off flags at most requires memory barriers, even
> in SMP boxen.  Do you have an example?

No, I was just pointing out grey areas in my own knowledge.

Keith

linux-2.5.18: DRM + cmpxchg issues

[Adam J. Richter]

	Under linux-2.5.18, several drivers for Direct Render Manager
(drivers/char/drm) call cmpxchg(), which is not defined for many
architectures including base i386 (i.e., if you want a kernel that runs
across the whole x86 processor line).

	2.5.18 also removed the cmpxchg() implementation for alpha that
was buried in drivers/char/drm, which I suspect was an incomplete patch
which was supposed to move the definition to somewhere in include/asm-alpha/.

	Here is the list of the effected DRM drivers;

	gamma.o
	i810.o		-- Pentium III chipset, requires AGP bus support
	i830.o		-- Pentium III chipset, requires AGP bus support
	mga.o		-- requires AGP bus
	r128.o
	radeon.o	-- requires AGP bus
	tdfx.o

	For, i830 and i830, I can define CONFIG_X86_CMPXCHG and use
the optimized cmpxchg(), because I know the code is running on a
Pentium III, regardless of the kernel compilation options.  The question
is what to do with the other drivers.  I guess my choices are:

	   1. Define CONFIG_X86_CMPXCHG in these drivers and have them abort
	      under x86 if a runtime check shows that the processor lacks
	      cmpxchg.  (It looks like 2.5.17 generated code that uesd
	      the cmpxchg without checking the processor type).

	   2. Write a generic cmpxchg routine (or find one in old
	      kernel sources) and use that in everything except i810.o
	      and i830.o.

	   3. Try to rewrite these drivers without cmpxchg.

	Any advice would be appreciated.

Adam J. Richter     __     ______________   575 Oroville Road
adam@yggdrasil.com     \ /                  Milpitas, California 95035
+1 408 309-6081         | g g d r a s i l   United States of America
                         "Free Software For The Rest Of Us."