> 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 oldversion of i915 that used to do it that way. i915 changed to polling pipestatin 2.6.36.

If there is no vblank to be waited for, we shouldn't be doingwait_for_vblank. If we're waiting for a pipe to turn off, there should be await_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 insleep_for_vblank and do pipestat polling in wait_for_vblank? Then I can starttesting sleep vs wait. All current wait_for_vblanks should be replaced withmdelay(20) and marked with a FIXME.

wait_for_pipe_disable can do mdelay(20) until something better comes up.