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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux