On Thu, 6 Mar 2014 11:28:13 +0200
Ville Syrjälä ville.syrj...@linux.intel.com wrote:
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 jbar...@virtuousgeek.org
---
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...
Yeah I could use unlock_all here instead, or be more careful about
dropping the specific crtc mutex we need. I did that on the crtc side
of things but obviously missed it here for cases where we'll hold the
crtc lock in this path.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
