On Wed, Jul 01, 2015 at 05:15:23PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > > Make sure we're not going to have weird races in really weird cases > where a lot of different CRTCs are doing rendering and modesets at the > same time. > > With this change and the stolen_lock from the previous patch, we can start > removing the struct_mutex locking we have around FBC in the next patches. > > v2: > - Rebase (6 months later) > - Also lock debugfs and stolen. > v3: > - Don't lock a single value read (Chris). > - Replace lockdep assertions with WARNs (Daniel). > - Improve commit message. > - Don't forget intel_pre_plane_update() locking. > v4: > - Don't remove struct_mutex at intel_pre_plane_update() (Chris). > - Add comment regarding locking dependencies (Chris). > - Rebase after the stolen code rework. > - Rebase again after drm-intel-nightly changes. > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> See below. > @@ -683,6 +721,8 @@ void intel_fbc_update(struct drm_device *dev) > const struct drm_display_mode *adjusted_mode; > unsigned int max_width, max_height; > > + WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock)); > + > if (!HAS_FBC(dev)) > return; This is now __intel_fbc_update() inside the fbc.lock. One would think that the internal functions would only be called when FBC is desired. That looks to be true, except for the new intel_fbc_update(). You can upgrade this to if (WARN_ON(!HAS_FBC(dev_priv))) return; after adding the proper guard to intel_fbc_update(). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
