On Mon, Jun 09, 2014 at 11:30:26AM +0300, Ville Syrjälä wrote: > On Mon, Jun 09, 2014 at 07:47:10AM +0100, Chris Wilson wrote: > > Thomas found that his machine would deadlock reloading the i915.ko > > module after resume. He identified that this was caused by the > > reacquisition of the connection mutex inside intel_enable_pipe_a() > > during the CRTC sanitization routine. This will only affect machines > > that quirk PIPE A, i.e. the original 830m chipsets. > > > > This patch move the locking into a wrapper function so that > > intel_enable_pipe_a() can bypass the locking knowing that it already > > holds the correct locks. > > It can still try to grab crtc->mutex twice. Looks like Danial undid my > fix to not take all the modeset locks around > intel_modeset_setup_hw_state().
Oh well, I only considered the santize_crtc path as I thought we would have caught the modeset sequence deadlocking earlier. Anyway, the locking is in flux due to the conversion to ww_mutex. Have fun ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
