From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
