On Wed, Mar 05, 2014 at 02:48:30PM -0800, Jesse Barnes wrote: > It takes awhile to fetch the DPCD and EDID for caching, so take it out > of the critical path to improve init time. > > Signed-off-by: Jesse Barnes <[email protected]> > --- > drivers/gpu/drm/i915/intel_dp.c | 113 > +++++++++++++++++++++++++++++----------- > 1 file changed, 82 insertions(+), 31 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 738c4e6..763f235 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3001,6 +3001,20 @@ intel_dp_handle_test_request(struct intel_dp *intel_dp) > intel_dp_aux_native_write_1(intel_dp, DP_TEST_RESPONSE, DP_TEST_NAK); > } > > +static void intel_flush_edp_cache_work(struct intel_dp *intel_dp) > +{ > + struct drm_device *dev = intel_dp->attached_connector->base.dev; > + > + WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); > + > + if (!is_edp(intel_dp)) > + return; > + > + mutex_unlock(&dev->mode_config.mutex); > + flush_work(&intel_dp->edp_cache_work); > + mutex_lock(&dev->mode_config.mutex);
This feels like deadlock land to me. If we drop mode_config.mutex someone else might grab it and then get blocked on the crtc mutex we're already holding, and then we try to re-grab mode_config.mutex... -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
