From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 5/6] drm/i915/dp: push eDP caching out into a work queue Date: Thu, 6 Mar 2014 11:28:13 +0200 Message-ID: <20140306092813.GB3852@intel.com> References: <1394059711-7910-1-git-send-email-jbarnes@virtuousgeek.org> <1394059711-7910-6-git-send-email-jbarnes@virtuousgeek.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTP id 612C9FAC09 for ; Thu, 6 Mar 2014 01:28:27 -0800 (PST) Content-Disposition: inline In-Reply-To: <1394059711-7910-6-git-send-email-jbarnes@virtuousgeek.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Jesse Barnes Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 > --- > 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 *inte= l_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 =3D 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=E4l=E4 Intel OTC