On Thursday, November 01, 2007 11:24 Mathieu Bérard wrote: > Jesse Barnes a écrit : > > I think this bit might cause problems. Since it doesn't look like > > you're using a hardware provided vblank count register, you'll want > > to keep vblank interrupts on after the first enable call so that > > it'll keep getting incremented in mach64_driver_irq_handler(), > > otherwise after the first disable() it'll stand still. Mostly this > > won't be a problem, but for some applications it's possible that it > > would cause them to hang or behave unexpectedly. > > I see that the actual vblank disabling code is also disabled for > r128 which doesn't seems to have an hardware vbl count register > neither. > Forgive my lack of global understanding of the whole issue but my > conclusion is that we just can't disable vbl interrupt on hardware > which lack vbl count in hardware, right ?
That's one option, yes. The other option is to calculate how many vblank interrupts have occurred between off and on periods. You could do this by recording the time when interrupts were disabled, figuring out how much time has passed between then and when they become enabled again, then dividing by the refresh rate. That should work in theory, but I don't think anyone's tried to do this in practice yet. Doing the latter will keep interrupts off more of the time, so it should save more power. Jesse ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
