On Fri, Nov 13, 2015 at 05:53:35PM -0200, Paulo Zanoni wrote: > There's no need to reevaluate the status of every single crtc when a > single crtc changes its state. > > With this, we're cutting the case where due to a change in pipe B, > intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC > should be enabled on pipe A, then it completely rechecks the state of > pipe A only to conclude FBC should remain enabled on pipe A. If any > change on pipe A triggers a need to recompute whether FBC is valid on > pipe A, then at some point someone is going to call > intel_fbc_update(PIPE_A). > > The addition of intel_fbc_deactivate() is necessary so we keep track > of the previously selected CRTC when we do invalidate/flush. We're > also going to continue the enable/disable/activate/deactivate concept > in the next patches. > > v2: Rebase. > v3: Rebase after changing the patch order. > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
