On Sat, Dec 26, 2009 at 02:46:29AM +0100, Rafał Miłecki wrote: > W dniu 24 grudnia 2009 08:19 użytkownik Michel Dänzer > <mic...@daenzer.net> napisał: > > I suspect the delay is more likely due to the workqueue than the > > interrupt itself. Way back when I implemented DRI1 tear-free buffer > > swaps for i945, I had to use a tasklet to reliably do work within the > > vertical blank period. > > I can not use tasklet as I need to sleep in setting engine function > (AtomBIOS command does it). > > First of all I converted Alex's code to take requested mode before > handling IRQ. Unfortunately that didn't help. Then I've converted > VBLANK sync from work queue to wait_event_interruptible_timeout and > wake_up_interruptible (btw. code seems much cleaner). This also didn't > help. > > There are some my experiments with engine. Reclocking between: > 1) 110MHz and 680MHz - 1 corrupted frame on every reclock > 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock > 3) 250MHz and 680MHz - no corruptions > 4) 340MHz and 680MHz - no corruptions > 5) 630MHz and 680MHz - no corruptions > > Maybe it's just downclocking to very low 110MHz that shouldn't happen? > My GPU works fine on this engine clock (no corruptions) but still > maybe reclocking to so low value can not be performed without > corruption? > > I don't think anymore it's timing related issue. > > -- > Rafał >
What is the screen resolution ? Cheers, Jerome ------------------------------------------------------------------------------ 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
