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 <kronos...@gmail.com>: > > > > On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: > > > >> 2009/12/28 Luca Tettamanti <kronos...@gmail.com>: > > > >> > 2009/12/28 Alex Deucher <alexdeuc...@gmail.com>: > > > >> >> On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti > > > >> >> <kronos...@gmail.com> wrote: > > > >> >>> On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki <zaj...@gmail.com> > > > >> >>> wrote: > > > >> >>>> W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher > > > >> >>>> <alexdeuc...@gmail.com> napisał: > > > >> >>>>> It may be that the engine doesn't like to be reclocked while it's > > > >> >>>>> running. Perhaps we should use the GUI idle interrupt rather > > > >> >>>>> than > > > >> >>>>> vblanks to reclock the engine. > > > >> >>>> > > > >> >>>> Could you say something more about GUI idle interrupt, please? > > > >> >>> > > > >> >>> It's mentioned in the documentation of the IH (see r600.c); I guess > > > >> >>> it's enabled by GUI_IDLE_INT_ENABLE. > > > >> >>> > > > >> >>>> What is this, do we already have code for that? > > > >> >>> > > > >> >>> Unless there are more subtleties all is needed it to enabled the > > > >> >>> interrupt and catch it in r600_irq_process. > > > >> >> > > > >> >> That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. > > > >> >> I can look up the details for that if they are not already > > > >> >> documented. > > > >> > > > > >> > I can't find a way to ack the interrupt; I see > > > >> > RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, > > > >> > right? > > > >> > > > >> You don't have to ACK it as the CP generates the interrupt in > > > >> software; similar to the sw interrupts used for fences. > > > > > > > > Ok, good: I've got the stub running on my M76. r100 and rs600 parts are > > > > untested. Comments? > > > > > > > > > > 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? This approach however reintroduces the issue with multiple active crtcs... Luca ------------------------------------------------------------------------------ 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
