Re: [PATCH 08/17] drm/i915: Wait for PHY port ready before link training on VLV/CHV

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

 




On 10/16/2014 11:27 AM, ville.syrjala@xxxxxxxxxxxxxxx wrote:
From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>

There's no point in checking if the data lanes came out of reset after
link training. If the data lanes aren't ready link training will fail
anyway.

Suggested-by: Todd Previte <tprevite@xxxxxxxxx>
Cc: Todd Previte <tprevite@xxxxxxxxx>
Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
---
If Todd has a better patch with better description we can use that one
instead of my version. But at least I think the spot where I put the
vlv_wait_port_ready() is the right one. We could perhaps skip the link
training attempt entirely if the port is already stuck.

  drivers/gpu/drm/i915/intel_dp.c | 7 +++----
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4c8f169..6f568b4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2550,6 +2550,9 @@ static void intel_enable_dp(struct intel_encoder *encoder)
pps_unlock(intel_dp); + if (IS_VALLEYVIEW(dev))
+		vlv_wait_port_ready(dev_priv, dp_to_dig_port(intel_dp));
+
  	intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
  	intel_dp_start_link_train(intel_dp);
  	intel_dp_complete_link_train(intel_dp);
@@ -2689,8 +2692,6 @@ static void vlv_pre_enable_dp(struct intel_encoder *encoder)
  	mutex_unlock(&dev_priv->dpio_lock);
intel_enable_dp(encoder);
-
-	vlv_wait_port_ready(dev_priv, dport);
  }
static void vlv_dp_pre_pll_enable(struct intel_encoder *encoder)
@@ -2783,8 +2784,6 @@ static void chv_pre_enable_dp(struct intel_encoder *encoder)
  	mutex_unlock(&dev_priv->dpio_lock);
intel_enable_dp(encoder);
-
-	vlv_wait_port_ready(dev_priv, dport);
  }
static void chv_dp_pre_pll_enable(struct intel_encoder *encoder)

We should definitely skip link training if the PHYs are down. There's going to be a WARN when wait_port_ready() fails so we'll be well aware that something went wrong. Spamming dmesg with errors/WARNs from trying to train the link after that is really counterproductive, since we already know there's no way link training could succeed.

-T
_______________________________________________
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