On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote:
> I've adapted Rafał's patch to do the reclock when the idle interrupt is
> fired (which btw should take care of the special case for nr CRTCs > 1).
> Unfortunately I still see the black frame when reclocking is performed.
> So I tried recloking directly from the IH (yeah, I'm ashamed of
> myself...); this got rid of the black frame, but causes corruption of a
> horizontal block of the screen (during the reclock, before and after the
> screen looks fine). In this second case I've added a spinlock to guard
> the access to the CP ring, so nothing touches it while reclocking is
> performed; however by the time we process the idle interrupt -
> especially considering that multiple events might be queued in the IH
> ring - someone else (i.e. one of the other cores) might already have
> submitted more work; what do you think?
Maybe a spinlock doesn't cut it. How about some mutex you take when you
need to reclock, to let tasks trying to add to the CP ring just sleep,
and then you unmask the idle interrupt. When you receive the idle
interrupt, you reclock, you free the mutex, and voilà.
Xav
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
