[Intel-gfx] [PATCH 0/3] FBC locking

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni at intel.com>

Release early, release often!

So patch 1 is not really FBC locking but it's another trivial patch from
December which I wanted to stop carrying around.

Patches 2 and 3 are the real locking thing. I know they could have been just a
single patch, but I decided to split them for bisectability reasons. We probably
shouldn't bisect anything to the "add the FBC mutex" patch, and if we bisect
something to the other patch, it will be easier to fix the problem - or revert -
if we already have fbc.lock. I can squash them if needed, no problem.

Notice that on patch 3 I remove the locking around a lot of calls from
intel_display.c. On a future patch I will completely remove all those calls and
rely only on the frontbuffer tracking infrastructure to update fbc through the
invalidate/flush functions. But before we can do this, we need an additional fix
which I'm already discussing with Daniel about.

The patches pass kms_frontbuffer_testing and kms_fbc_crc without any lockdep
assertions.

Thanks,
Paulo

Paulo Zanoni (3):
  drm/i915: don't increment the FBC threshold at fbc_enable
  drm/i915: add the FBC mutex
  drm/i915: stop using struct_mutex for FBC

 drivers/gpu/drm/i915/i915_debugfs.c    |  10 ++--
 drivers/gpu/drm/i915/i915_drv.h        |   1 +
 drivers/gpu/drm/i915/i915_gem_stolen.c |   7 +++
 drivers/gpu/drm/i915/intel_display.c   |  18 +-----
 drivers/gpu/drm/i915/intel_drv.h       |   1 +
 drivers/gpu/drm/i915/intel_fbc.c       | 101 ++++++++++++++++++++++++++-------
 6 files changed, 99 insertions(+), 39 deletions(-)

-- 
2.1.4