From: Luca T. <kro...@gm...> - 2009-12-30 23:10:28
|
On Wed, Dec 30, 2009 at 10:56 AM, Luca Tettamanti <kro...@gm...> wrote: > On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote: >> On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: >> > Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: >> > > 2009/12/28 Luca Tettamanti <kro...@gm...>: >> > > > On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: >> > > Looks pretty good. I've included the proper defines from the register >> > > database below and you'll need to ack the gui idle interrupts on >> > > pre-r600 chips. Now you just have to do something when you get the >> > > idle interrupt. >> > >> > 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). >> >> If you mean the interrupt handler for the idle interrupt, > > Yes. > >> have you tried >> doing it in the interrupt handler for the vblank interrupt instead? > > Not yet; I've tried a solution similar to what Xavier suggested: lock the ring, > wait for idle, reclock (outside the IH), unlock and it still causes corruption > (but not the black frame). > > The next iteration would be: > > lock cp > wait for idle > enable vblank > wait for vlbank > relock > unlock cp > > With reclock that might be moved to the vblank interrupt if it still causes > problems. Sounds sensible? I still see corruption... this is what I'm doing: <driver decides to reclock> take cp.mutex wait_event(gui_idle) idle interrupt { set idle flag wake_up() } drm_vblank_get vblank interrupt { reclock() } drm_vblank_put release cp.mutex -ENOIDEA Luca |