On Fri, Nov 13, 2015 at 05:53:37PM -0200, Paulo Zanoni wrote: > The goal is to call FBC enable/disable only once per modeset, while > activate/deactivate/update will be called multiple times. > > The enable() function will be responsible for deciding if a CRTC will > have FBC on it and then it will "lock" FBC on this CRTC: it won't be > possible to change FBC's CRTC until disable(). With this, all checks > and resource acquisition that only need to be done once per modeset > can be moved from update() to enable(). And then the update(), > activate() and deactivate() code will also get simpler since they > won't need to worry about the CRTC being changed. > > The disable() function will do the reverse operation of enable(). One > of its features is that it should only be called while the pipe is > already off. This guarantees that FBC is stopped and nothing is > using the CFB. > > With this, the activate() and deactivate() functions just start and > temporarily stop FBC. They are the ones touching the hardware enable > bit, so HW state reflects dev_priv->crtc.active. > > The last function remaining is update(). A lot of times I thought > about renaming update() to activate() or try_to_activate() since it's > called when we want to activate FBC. The thing is that update() may > not only decide to activate FBC, but also deactivate or keep it on the > same state, so I'll leave this name for now. > > Moving code to enable() and disable() will also help in case we decide > to move FBC to pipe_config or something else later. > > The current patch only puts the very basic code on enable() and > disable(). The next commits will take care of moving more stuff from > update() to the new functions. > > v2: > - Rebase. > - Improve commit message (Chris). > v3: Rebase after changing the patch order. > v4: Rebase again after upstream changes. > > 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
