On Sat, May 24, 2014 at 8:30 PM, Rob Clark <robdclark@xxxxxxxxx> wrote:
> @@ -8002,7 +8002,7 @@ bool intel_get_load_detect_pipe(struct drm_connector *connector,
> if (encoder->crtc) {
> crtc = encoder->crtc;
>
> - mutex_lock(&crtc->mutex);
> + drm_modeset_lock(&crtc->mutex, NULL);
This is pretty much the reason why I think switching the
mode_config.mutex to a ww_mutex is a bad idea: This call here nests
within the mode_config.mutex and so must be acquired. Wiring the
acquire context through everything is going to be fairly horrible,
especially since you must be able to bail out when trying to lock with
an axquire context.
My original design behind the crtc->mutex and mode_config.mutex split
was that as long as the connector->crtc links didn't change you can
get away with the crtc lock. setplane made a bit a mess out of this,
but strictly speaking as long as you acquire all crtc locks involved
in a potential plane switch (which ww_mtuxes can do) it'll be fine.
Since noticing whether any connector properties change should be
doable upfront I think we should try _really_ hard to keep the
mode_config.mutex a plain mutex which wraps all the more fine-grained
locks and is a catch-all for everything else but crtcs/planes.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
