Your patch is much, much prettier than mine (which is in mainline),
and Linus is hoping for such a prettier solution.

On the other hand, is there any reason we're taking this
rinfo->reg_lock?   Would it be possible for the fb driver to be called
in two separate contexts at the same time?

QUick fix from the original code I took over from, never had time to
rework that part. I still plan to rewrite most of the mode setting
code in there to, among others, deal with dual head & such, but I lack
time and it's a lot of work.

Also, having this macro be pretty sort of obsccures the fact that, 
the way the code is now, we're doing

	OUTPLL(foo0, bar0);
	OUTPLL(foo1, bar1);
	OUTPLL(foo2, bar2);

which translates to taking this lock three times in quick succession.
Bleah.

I had half a mind to put a radeon_fifo_wait() call in the
OUTREG() macro (because there needs to be a 1-1 correspondence 
between empty fifo slots and OUTREG calls, but then you add a
chunk of a loop, udelay, and printk to every register write...
again lots of overhead for a simple register write.... 
better to sprinkle the code with the write counts and hope they stay
in line?  Maybe.  That's the route I took, anyways.

-dte

-- 
Benjamin Herrenschmidt [off-list ref]



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com