On Mon, Nov 3, 2014 at 7:37 PM, Paulo Zanoni <przanoni@xxxxxxxxx> wrote: > Besides this, my only worry is what is going to happen if we disable > the CRTC or plane (or even suspend - S3 or runtime - or something like > that) after we schedule the work, but before the work actually > happens. Isn't it possible to end up accidentally reenabling something > that was just disabled? We can't seem to queue a new flip before the > current one finishes, but maybe we can shut down the CRTC while the > work is scheduled? I don't know much about vblanks to properly answer > that, so I'll let Daniel/Ville take a look at this. We do wait for pageflips to complete before disabling the crtc or updating the framebuffer. But I don't think we actually lack the corresponding code to do the same when disabling the pipe with dpms off. We have extensive sets of testcases to race pageflips against almost any combination of dpms calls, setCrtc changes, vblank waits or any other nonsense, so if that still works we should be good I think. Or maybe that's the reason why kms_flip has such a poor pass-rate? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx