2001-01-02 4:58 GMT-02:00 Paulo Zanoni <przanoni@xxxxxxxxx>: > 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. For some reason the email came with a date of 2001. So let's bump the thread to the top of people's inboxes using this reply. Sorry. > > 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 > -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
