> Opinions are cheap, generating a list of all the paths through the tree > that can hit vblank waits is alas not, neither is verifying it on a pile > of real hardware 8( Yes, it certainly needs testing before being changed. > Plus none of the Intel issued IMG drivers wait for a vblank event and in > several cases it's quite clear that there is *no* vblank that can be > waited for at that point, eg look at the MIPI interfaces. I don't think there is a particular reason for that. They are based on an old version of i915 that used to do it that way. i915 changed to polling pipestat in 2.6.36. If there is no vblank to be waited for, we shouldn't be doing wait_for_vblank. If we're waiting for a pipe to turn off, there should be a wait_for_pipe_disable, and so on.. > So unfortunately it's rather complicated to fix although working them > through to make some of the msleeps is certainly doable - add a > sleep_for_vblank() or similar and send patches as you verify each one is > ok and test it perhaps ? > > Alan What about catching vblanks in irq handler and using a wait queue in sleep_for_vblank and do pipestat polling in wait_for_vblank? Then I can start testing sleep vs wait. All current wait_for_vblanks should be replaced with mdelay(20) and marked with a FIXME. wait_for_pipe_disable can do mdelay(20) until something better comes up. If that is ok with you, I'll send some patches. Patrik _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
