Re: radeon_pm.c locking problem

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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 <benh@kernel.crashing.org>



-------------------------------------------------------
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