[Intel-gfx] [PATCH] drm/i915: Avoid double mutex lock applying pipe A quirk during sanitize_crtc()

[Chris Wilson]

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