From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> Hi So this is a new take on the FBC locking improvements. This time I continue with the "introduce fbc.lock first, then reduce struct_mutex later" strategy in order to minimize the risks and facilitate review. I also fixed a "lack of struct_mutex lock" regression I introduced when I first moved FBC to the frontbuffer tracking infrastructure. Right now the only places where we should be holding the struct_mutex lock for FBC is on the 2 intel_fbc_update() calls: one at intel_post_plane_update() and another at intel_unpin_work_fn(). Notice that we'll probably remove the intel_fbc_update() call that's inside intel_unpin_work_fn() later, so we'll only required struct_mutex locking once. We can't get rid of the single struct_mutex lock requirement since we need to deal with the CFB allocation. Of course we can always rework that code a little bit more, but let's do it on later patches. Thanks, Paulo Paulo Zanoni (8): drm/i915: don't increment the FBC threshold at fbc_enable drm/i915: add the FBC mutex drm/i915: remove unneded locks on debugs FBC functions drm/i915: remove struct_mutex lock from the FBC work function drm/i915: simplify FBC start/stop at invalidate/flush drm/i915: add struct_mutex WARNs to i915_gem_stolen.c drm/i915: reduce struct_mutex coverage at intel_crtc_page_flip() drm/i915: remove struct_mutex lock from intel_modeset_cleanup() drivers/gpu/drm/i915/i915_debugfs.c | 8 +-- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem_stolen.c | 20 ++++++ drivers/gpu/drm/i915/intel_display.c | 16 +---- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_fbc.c | 110 +++++++++++++++++++++++++++------ 6 files changed, 120 insertions(+), 36 deletions(-) -- 2.1.4 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
