On Wed, Dec 30, 2009 at 10:56 AM, Luca Tettamanti <[email protected]> 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 <[email protected]>:
>> > > > 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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
