On Thursday, November 01, 2007 12:06 Mathieu Bérard wrote: > Jesse Barnes a écrit : > >> 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. > > That sound great but another harder to met criteria is for > the drm layer to be able to keep track if > the refresh rates change during an irq off period, right ?
Yeah, it's definitely trickier to do. Client applications should be using the new modesetting ioctl in the vblank-rework tree to tell the DRM core when the mode has changed though, so it should be possible to calculate a new refresh rate at that time (possibly by leaving interrupts on for a time until a stable number emerges or by extending the ioctl to include a refresh rate). 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
