2014-11-03 16:53 GMT-02:00 Daniel Vetter <daniel@xxxxxxxx>: > 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, as far as I can see, those functions do not take into consideration the new workqueue added by this patch. > 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 -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
