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ł ------------------------------------------------------------------------------ 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
