FBC locking v3

From: Paulo Zanoni <[email protected]>

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
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx