[Intel-gfx] [PATCH 05/12] drm/i915: introduce intel_fbc_{enable, disable}

Chris Wilson chris at chris-wilson.co.uk
Fri Nov 13 13:11:12 PST 2015


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 at intel.com>
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list