[3/3] drm/i915: Support DDI lane reversal for DP
diff mbox

Message ID 20150805193427.GA6097@mail.corp.redhat.com
State New
Headers show

Commit Message

Benjamin Tissoires Aug. 5, 2015, 7:34 p.m. UTC
On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
> 
> 
> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >>identify both lane count and reversal state without touching anything in the
> >>link training code. i am yet to upstream my changes for CHT that i can share
> >>if required that does the same in intel_dp_detect without touching any line
> >>in link training path.
> >With my current limited knowledge of the dp hotplug (and i915 driver) I
> >am not sure we could detect the reversed state without trying to train 1
> >lane only. I'd be glad to look at your changes and test them on my
> >system if you think that could help having a cleaner solution.
> >
> >Cheers,
> >Benjamin
> No, what i recommended was to do link training but in intel_dp_detect. Since
> USB Type C cable
> also has its own lane count restriction (it can have different lane count
> than the one supported
> by panel) you might have to figure that out as well. so both reversal and
> lane count detection
> can be done outside the modeset path and keep the code free of type C
> changes outside
> detection path.
> 
> Please find below the code to do the same. Do not waste time trying to apply
> this directly on
> nightly since this is based on a local tree and because this is pre- atomic
> changes code, so you
> might have to modify chv_upfront_link_train to work on top of the latest
> nightly code. we
> are supposed to upstream this and is in my todo list.
> 

[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?

My patch is now:

From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
From: Durgadoss R <durgadoss.r@intel.com>
Date: Mon, 3 Aug 2015 11:51:16 -0400
Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support

To support USB type C alternate DP mode, the display driver needs to know the
number of lanes required by DP panel as well as number of lanes that can be
supported by the type-C cable. Sometimes, the type-C cable may limit the
bandwidth even if Panel can support more lanes. To address these scenarios,
the display driver will start link training with max lanes, and if the link
training fails, the driver then falls back to x2 lanes.

* Since link training is done before modeset, planes are not enabled. Only
  encoder and the its associated PLLs are enabled.
* Once link training is done, the encoder and its PLLs are disabled; so that
  the subsequent modeset is not aware of these changes.
* As of now, this is tested only on CHV.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
[BT: add broadwell support and USB-C reverted state detection]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
 drivers/gpu/drm/i915/intel_display.c | 163 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_dp.c      |  22 ++++-
 drivers/gpu/drm/i915/intel_drv.h     |   7 ++
 3 files changed, 190 insertions(+), 2 deletions(-)

Comments

Sivakumar Thulasimani Aug. 6, 2015, 9:41 a.m. UTC | #1
On 8/6/2015 1:04 AM, Benjamin Tissoires wrote:
> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>
>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>>> On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>>> why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
>>>> identify both lane count and reversal state without touching anything in the
>>>> link training code. i am yet to upstream my changes for CHT that i can share
>>>> if required that does the same in intel_dp_detect without touching any line
>>>> in link training path.
>>> With my current limited knowledge of the dp hotplug (and i915 driver) I
>>> am not sure we could detect the reversed state without trying to train 1
>>> lane only. I'd be glad to look at your changes and test them on my
>>> system if you think that could help having a cleaner solution.
>>>
>>> Cheers,
>>> Benjamin
>> No, what i recommended was to do link training but in intel_dp_detect. Since
>> USB Type C cable
>> also has its own lane count restriction (it can have different lane count
>> than the one supported
>> by panel) you might have to figure that out as well. so both reversal and
>> lane count detection
>> can be done outside the modeset path and keep the code free of type C
>> changes outside
>> detection path.
>>
>> Please find below the code to do the same. Do not waste time trying to apply
>> this directly on
>> nightly since this is based on a local tree and because this is pre- atomic
>> changes code, so you
>> might have to modify chv_upfront_link_train to work on top of the latest
>> nightly code. we
>> are supposed to upstream this and is in my todo list.
>>
> [original patch snipped...]
>
> Hi Sivakumar,
>
> So I managed to manually re-apply your patch on top of
> drm-intel-nightly, and tried to port it to make Broadwell working too.
> It works OK if the system is already boot without any external DP used.
> In this case, the detection works and I can see my external monitor
> working properly.
>
> However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> understand why. I think I enabled all that is mentioned in the PRM to be
> able to train the DP link, but I am obviously missing something else.
> Can you have a look?
>
> My patch is now:
</snipping some more>
>
> @@ -4495,7 +4499,9 @@ intel_dp_detect(struct drm_connector *connector, bool force)
>   	struct intel_dp *intel_dp = intel_attached_dp(connector);
>   	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   	struct intel_encoder *intel_encoder = &intel_dig_port->base;
> +	struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
>   	struct drm_device *dev = connector->dev;
> +	struct intel_crtc *intel_crtc;
>   	enum drm_connector_status status;
>   	enum intel_display_power_domain power_domain;
>   	bool ret;
> @@ -4540,6 +4546,18 @@ intel_dp_detect(struct drm_connector *connector, bool force)
>   
>   	if (intel_encoder->type != INTEL_OUTPUT_EDP)
>   		intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> +
> +	if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT &&
> +	    (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))) {
> +		/* Do not handle connected boot scenario where panel is enabled
> +		 * by GOP/VBIOS.
> +		 */
> +		if ((connector->status != connector_status_connected) &&
> +		    !(intel_encoder->connectors_active &&
> +		      crtc && crtc->enabled))
> +			intel_upfront_link_train(dev, intel_dp, NULL);
> +	}
> +
here you are calling intel_upfront_link_train only if display is plugged 
in and there is no crtc associated with it.
hence your code is working on hotplug. modify the above to consider 
scenario when crtc is set and enabled
which happens when you plug in dp and boot the system. a good pointer is 
the original code :)
+        if (intel_encoder->connectors_active &&
+                        crtc && crtc->enabled) {
+            intel_crtc = to_intel_crtc(crtc);
+            DRM_DEBUG_KMS("Disabling crtc %c for upfront link training\n",
+                    pipe_name(intel_crtc->pipe));
+            intel_crtc_control(crtc, false);
+        }

But again, all these are experimental :), any point you touch crtc it is 
not in line with the new "atomic"
thinking and will not be allowed upstream till it is fixed as per the 
new way :).


>   	status = connector_status_connected;
>   
>   	/* Try to read the source of the interrupt */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 320c9e6..fcc95d5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1163,6 +1163,13 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>   void intel_dp_start_link_train(struct intel_dp *intel_dp);
>   void intel_dp_complete_link_train(struct intel_dp *intel_dp);
>   void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> +bool intel_upfront_link_train(struct drm_device *dev,
> +			      struct intel_dp *intel_dp,
> +			      struct intel_crtc *crtc);
> +void hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw);
> +void intel_dp_set_clock(struct intel_encoder *encoder,
> +			struct intel_crtc_state *pipe_config, int link_bw);
> +
>   void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
>   void intel_dp_encoder_destroy(struct drm_encoder *encoder);
>   int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
Stéphane Marchesin Aug. 14, 2015, 11:27 p.m. UTC | #2
On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>
>>
>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
>> >>identify both lane count and reversal state without touching anything in the
>> >>link training code. i am yet to upstream my changes for CHT that i can share
>> >>if required that does the same in intel_dp_detect without touching any line
>> >>in link training path.
>> >With my current limited knowledge of the dp hotplug (and i915 driver) I
>> >am not sure we could detect the reversed state without trying to train 1
>> >lane only. I'd be glad to look at your changes and test them on my
>> >system if you think that could help having a cleaner solution.
>> >
>> >Cheers,
>> >Benjamin
>> No, what i recommended was to do link training but in intel_dp_detect. Since
>> USB Type C cable
>> also has its own lane count restriction (it can have different lane count
>> than the one supported
>> by panel) you might have to figure that out as well. so both reversal and
>> lane count detection
>> can be done outside the modeset path and keep the code free of type C
>> changes outside
>> detection path.
>>
>> Please find below the code to do the same. Do not waste time trying to apply
>> this directly on
>> nightly since this is based on a local tree and because this is pre- atomic
>> changes code, so you
>> might have to modify chv_upfront_link_train to work on top of the latest
>> nightly code. we
>> are supposed to upstream this and is in my todo list.
>>
>
> [original patch snipped...]
>
> Hi Sivakumar,
>
> So I managed to manually re-apply your patch on top of
> drm-intel-nightly, and tried to port it to make Broadwell working too.
> It works OK if the system is already boot without any external DP used.
> In this case, the detection works and I can see my external monitor
> working properly.
>
> However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> understand why. I think I enabled all that is mentioned in the PRM to be
> able to train the DP link, but I am obviously missing something else.
> Can you have a look?
>

Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.

Stéphane



> My patch is now:
>
> From 11e9c42f55ae27bd6e7b0168bf24d15082c7d517 Mon Sep 17 00:00:00 2001
> From: Durgadoss R <durgadoss.r@intel.com>
> Date: Mon, 3 Aug 2015 11:51:16 -0400
> Subject: [PATCH] drm/i915: Enable Upfront link training for type-C DP support
>
> To support USB type C alternate DP mode, the display driver needs to know the
> number of lanes required by DP panel as well as number of lanes that can be
> supported by the type-C cable. Sometimes, the type-C cable may limit the
> bandwidth even if Panel can support more lanes. To address these scenarios,
> the display driver will start link training with max lanes, and if the link
> training fails, the driver then falls back to x2 lanes.
>
> * Since link training is done before modeset, planes are not enabled. Only
>   encoder and the its associated PLLs are enabled.
> * Once link training is done, the encoder and its PLLs are disabled; so that
>   the subsequent modeset is not aware of these changes.
> * As of now, this is tested only on CHV.
>
> Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
> [BT: add broadwell support and USB-C reverted state detection]
> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 163 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_dp.c      |  22 ++++-
>  drivers/gpu/drm/i915/intel_drv.h     |   7 ++
>  3 files changed, 190 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 818f3a3..e8ddba0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15799,3 +15799,166 @@ void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
>                 spin_unlock_irq(&dev->event_lock);
>         }
>  }
> +
> +static bool
> +intel_upfront_link_train_config(struct drm_device *dev,
> +                               struct intel_dp *intel_dp,
> +                               struct intel_crtc *crtc,
> +                               uint8_t link_bw,
> +                               uint8_t lane_count)
> +{
> +       struct drm_i915_private *dev_priv = dev->dev_private;
> +       struct intel_connector *connector = intel_dp->attached_connector;
> +       struct intel_encoder *encoder = connector->encoder;
> +       bool success;
> +
> +       intel_dp->link_bw = link_bw;
> +       intel_dp->lane_count = lane_count;
> +
> +       /* Find port clock from link_bw */
> +       crtc->config->port_clock = drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
> +
> +       /* Enable PLL followed by port */
> +       if (IS_BROADWELL(dev)) {
> +               hsw_dp_set_ddi_pll_sel(crtc->config, intel_dp->link_bw);
> +               if (intel_crtc_to_shared_dpll(crtc))
> +                       intel_enable_shared_dpll(crtc);
> +
> +               intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
> +
> +       } else if (IS_CHERRYVIEW(dev)) {
> +               intel_dp_set_clock(encoder, crtc->config, intel_dp->link_bw);
> +               if (encoder->pre_pll_enable)
> +                       encoder->pre_pll_enable(encoder);
> +               if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
> +                       chv_enable_pll(crtc, crtc->config);
> +       }
> +       if (encoder->pre_enable)
> +               encoder->pre_enable(encoder);
> +
> +       success = intel_dp->train_set_valid;
> +
> +       /* Reset encoder for next retry or for clean up */
> +       if (encoder->post_disable)
> +               encoder->post_disable(encoder);
> +       if (IS_CHERRYVIEW(dev)) {
> +               if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
> +                       chv_disable_pll(dev_priv, crtc->pipe);
> +       } else if (IS_BROADWELL(dev)) {
> +               intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
> +               if (intel_crtc_to_shared_dpll(crtc))
> +                       intel_disable_shared_dpll(crtc);
> +       }
> +
> +       intel_dp->train_set_valid = false;
> +
> +       return success;
> +}
> +
> +bool
> +intel_upfront_link_train(struct drm_device *dev,
> +                        struct intel_dp *intel_dp,
> +                        struct intel_crtc *crtc)
> +{
> +       struct intel_connector *connector = intel_dp->attached_connector;
> +       struct intel_encoder *encoder = connector->encoder;
> +       struct intel_digital_port *intel_dig_port = enc_to_dig_port(&encoder->base);
> +       uint8_t link_bw, lane_count;
> +       bool found = false;
> +       bool valid_crtc = !!crtc;
> +
> +       if (!connector || !encoder) {
> +               DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
> +               return false;
> +       }
> +
> +       /* Find an unused crtc and use it for link training if no crtc is given */
> +       if (!crtc) {
> +               for_each_intel_crtc(dev, crtc) {
> +                       if (intel_crtc_active(&crtc->base))
> +                               continue;
> +
> +                       /* Make sure the new crtc will work with the encoder */
> +                       if (!drm_encoder_crtc_ok(&encoder->base, &crtc->base))
> +                               continue;
> +
> +                       encoder->base.crtc = &crtc->base;
> +
> +                       found = true;
> +                       break;
> +               }
> +
> +               if (!found) {
> +                       DRM_ERROR("Could not find crtc for upfront link training\n");
> +                       goto exit;
> +               }
> +       }
> +
> +       DRM_DEBUG_KMS("upfront link training on pipe:%c\n",
> +                     pipe_name(crtc->pipe));
> +
> +       /* check the reversed state of the adapter first */
> +
> +       /* unset the reversal bit */
> +       intel_dig_port->saved_port_bits &= ~DDI_BUF_PORT_REVERSAL;
> +
> +       /* Initialize with Max Link rate supported by panel & one lane */
> +       intel_dp->link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
> +       intel_dp->lane_count = 1;
> +
> +       /* Check if link training passed; if not, update the reversed state */
> +       if (!intel_upfront_link_train_config(dev, intel_dp, crtc,
> +                                       intel_dp->dpcd[DP_MAX_LINK_RATE], 1))
> +               intel_dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
> +
> +       found = false;
> +
> +       /* Initialize with Max Link rate & lane count supported by panel */
> +       link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
> +       lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
> +
> +       do {
> +               /* Check if link training passed; if so update lane count */
> +               if (intel_upfront_link_train_config(dev, intel_dp, crtc,
> +                                       link_bw, lane_count)) {
> +                       intel_dp->dpcd[DP_MAX_LANE_COUNT] &=
> +                                               ~DP_MAX_LANE_COUNT_MASK;
> +                       intel_dp->dpcd[DP_MAX_LANE_COUNT] |=
> +                               intel_dp->lane_count & DP_MAX_LANE_COUNT_MASK;
> +
> +                       found = true;
> +                       goto exit;
> +               }
> +
> +               DRM_DEBUG_KMS("upfront link training failed. lanes:%d bw:%d\n",
> +                               intel_dp->lane_count, intel_dp->link_bw);
> +
> +               /* Go down to the next level and retry link training */
> +               if (lane_count == 4) {
> +                       lane_count = 2;
> +               } else if (lane_count == 2) {
> +                       lane_count = 1;
> +               } else if (link_bw == DP_LINK_BW_5_4) {
> +                       link_bw = DP_LINK_BW_2_7;
> +                       lane_count = 4;
> +               } else if (link_bw == DP_LINK_BW_2_7) {
> +                       link_bw = DP_LINK_BW_1_62;
> +                       lane_count = 4;
> +               } else {
> +                       /* Tried all combinations, so exit */
> +                       break;
> +               }
> +
> +       } while (1);
> +
> +exit:
> +       /* Clear local associations made */
> +       if (!valid_crtc)
> +               encoder->base.crtc = NULL;
> +
> +       if (found)
> +               DRM_DEBUG_KMS("upfront link training passed. lanes:%d bw:%d\n",
> +                               intel_dp->lane_count, intel_dp->link_bw);
> +
> +       return found;
> +}
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 44f8a32..187800b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1144,7 +1144,7 @@ skl_edp_set_pll_config(struct intel_crtc_state *pipe_config, int link_clock)
>         pipe_config->dpll_hw_state.ctrl1 = ctrl1;
>  }
>
> -static void
> +void
>  hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw)
>  {
>         memset(&pipe_config->dpll_hw_state, 0,
> @@ -1202,7 +1202,7 @@ intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
>                 return (DP_LINK_BW_2_7 >> 3) + 1;
>  }
>
> -static void
> +void
>  intel_dp_set_clock(struct intel_encoder *encoder,
>                    struct intel_crtc_state *pipe_config, int link_bw)
>  {
> @@ -4423,6 +4423,10 @@ g4x_dp_detect(struct intel_dp *intel_dp)
>         else if (ret == 0)
>                 return connector_status_disconnected;
>
> +       /* Avoid DPCD opertations if status is same */
> +       if (intel_dp->attached_connector->base.status == connector_status_connected)
> +               return connector_status_connected;
> +
>         return intel_dp_detect_dpcd(intel_dp);
>  }
>
> @@ -4495,7 +4499,9 @@ intel_dp_detect(struct drm_connector *connector, bool force)
>         struct intel_dp *intel_dp = intel_attached_dp(connector);
>         struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>         struct intel_encoder *intel_encoder = &intel_dig_port->base;
> +       struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
>         struct drm_device *dev = connector->dev;
> +       struct intel_crtc *intel_crtc;
>         enum drm_connector_status status;
>         enum intel_display_power_domain power_domain;
>         bool ret;
> @@ -4540,6 +4546,18 @@ intel_dp_detect(struct drm_connector *connector, bool force)
>
>         if (intel_encoder->type != INTEL_OUTPUT_EDP)
>                 intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
> +
> +       if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT &&
> +           (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))) {
> +               /* Do not handle connected boot scenario where panel is enabled
> +                * by GOP/VBIOS.
> +                */
> +               if ((connector->status != connector_status_connected) &&
> +                   !(intel_encoder->connectors_active &&
> +                     crtc && crtc->enabled))
> +                       intel_upfront_link_train(dev, intel_dp, NULL);
> +       }
> +
>         status = connector_status_connected;
>
>         /* Try to read the source of the interrupt */
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 320c9e6..fcc95d5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1163,6 +1163,13 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
>  void intel_dp_start_link_train(struct intel_dp *intel_dp);
>  void intel_dp_complete_link_train(struct intel_dp *intel_dp);
>  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> +bool intel_upfront_link_train(struct drm_device *dev,
> +                             struct intel_dp *intel_dp,
> +                             struct intel_crtc *crtc);
> +void hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw);
> +void intel_dp_set_clock(struct intel_encoder *encoder,
> +                       struct intel_crtc_state *pipe_config, int link_bw);
> +
>  void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
>  void intel_dp_encoder_destroy(struct drm_encoder *encoder);
>  int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
> --
> 2.4.3
>
>
> Cheers,
> Benjamin
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Benjamin Tissoires Aug. 17, 2015, 8:06 p.m. UTC | #3
On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
> On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> > On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>
> >>
> >> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >> >>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >> >>identify both lane count and reversal state without touching anything in the
> >> >>link training code. i am yet to upstream my changes for CHT that i can share
> >> >>if required that does the same in intel_dp_detect without touching any line
> >> >>in link training path.
> >> >With my current limited knowledge of the dp hotplug (and i915 driver) I
> >> >am not sure we could detect the reversed state without trying to train 1
> >> >lane only. I'd be glad to look at your changes and test them on my
> >> >system if you think that could help having a cleaner solution.
> >> >
> >> >Cheers,
> >> >Benjamin
> >> No, what i recommended was to do link training but in intel_dp_detect. Since
> >> USB Type C cable
> >> also has its own lane count restriction (it can have different lane count
> >> than the one supported
> >> by panel) you might have to figure that out as well. so both reversal and
> >> lane count detection
> >> can be done outside the modeset path and keep the code free of type C
> >> changes outside
> >> detection path.
> >>
> >> Please find below the code to do the same. Do not waste time trying to apply
> >> this directly on
> >> nightly since this is based on a local tree and because this is pre- atomic
> >> changes code, so you
> >> might have to modify chv_upfront_link_train to work on top of the latest
> >> nightly code. we
> >> are supposed to upstream this and is in my todo list.
> >>
> >
> > [original patch snipped...]
> >
> > Hi Sivakumar,
> >
> > So I managed to manually re-apply your patch on top of
> > drm-intel-nightly, and tried to port it to make Broadwell working too.
> > It works OK if the system is already boot without any external DP used.
> > In this case, the detection works and I can see my external monitor
> > working properly.
> >
> > However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> > understand why. I think I enabled all that is mentioned in the PRM to be
> > able to train the DP link, but I am obviously missing something else.
> > Can you have a look?
> >
> 
> Hi Benjamin,
> 
> I would recommend against this approach. Some adapters will claim that
> they recovered a clock even when it isn't on the lanes you enabled,
> which means that the reversal detection doesn't always work. The only
> reliable way to do this is to go talk to the Chrome OS EC (you can
> find these patches later in the Chrome OS tree). It's not as generic,
> but we might be able to abstract that logic, maybe.
> 

Hi Stéphane,

This is a very good news. I was afraid we would not have access to the
hardware controller because the Intel controller hub spec was not
public.

I will try to have a look at it, but the latest chromeos branch (3.18)
seems to differ quite a lot from the upstream one. Anyway, fingers
crossed.

Cheers,
Benjamin
Sivakumar Thulasimani Aug. 26, 2015, 12:09 p.m. UTC | #4
On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:
> On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
>> On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
>> <benjamin.tissoires@redhat.com> wrote:
>>> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>>>
>>>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>>>>> On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>>>>> why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
>>>>>> identify both lane count and reversal state without touching anything in the
>>>>>> link training code. i am yet to upstream my changes for CHT that i can share
>>>>>> if required that does the same in intel_dp_detect without touching any line
>>>>>> in link training path.
>>>>> With my current limited knowledge of the dp hotplug (and i915 driver) I
>>>>> am not sure we could detect the reversed state without trying to train 1
>>>>> lane only. I'd be glad to look at your changes and test them on my
>>>>> system if you think that could help having a cleaner solution.
>>>>>
>>>>> Cheers,
>>>>> Benjamin
>>>> No, what i recommended was to do link training but in intel_dp_detect. Since
>>>> USB Type C cable
>>>> also has its own lane count restriction (it can have different lane count
>>>> than the one supported
>>>> by panel) you might have to figure that out as well. so both reversal and
>>>> lane count detection
>>>> can be done outside the modeset path and keep the code free of type C
>>>> changes outside
>>>> detection path.
>>>>
>>>> Please find below the code to do the same. Do not waste time trying to apply
>>>> this directly on
>>>> nightly since this is based on a local tree and because this is pre- atomic
>>>> changes code, so you
>>>> might have to modify chv_upfront_link_train to work on top of the latest
>>>> nightly code. we
>>>> are supposed to upstream this and is in my todo list.
>>>>
>>> [original patch snipped...]
>>>
>>> Hi Sivakumar,
>>>
>>> So I managed to manually re-apply your patch on top of
>>> drm-intel-nightly, and tried to port it to make Broadwell working too.
>>> It works OK if the system is already boot without any external DP used.
>>> In this case, the detection works and I can see my external monitor
>>> working properly.
>>>
>>> However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
>>> understand why. I think I enabled all that is mentioned in the PRM to be
>>> able to train the DP link, but I am obviously missing something else.
>>> Can you have a look?
>>>
>> Hi Benjamin,
>>
>> I would recommend against this approach. Some adapters will claim that
>> they recovered a clock even when it isn't on the lanes you enabled,
>> which means that the reversal detection doesn't always work. The only
>> reliable way to do this is to go talk to the Chrome OS EC (you can
>> find these patches later in the Chrome OS tree). It's not as generic,
>> but we might be able to abstract that logic, maybe.
>>
> Hi Stéphane,
>
> This is a very good news. I was afraid we would not have access to the
> hardware controller because the Intel controller hub spec was not
> public.
>
> I will try to have a look at it, but the latest chromeos branch (3.18)
> seems to differ quite a lot from the upstream one. Anyway, fingers
> crossed.
>
> Cheers,
> Benjamin
Hi Benjamin/Stéphan,
     All Intel platforms (at-least those i inquired about) handle lane 
reversal in HW.
your statement that link training will pass even on reversed lane seems 
to point
to the same fact. in such a scenario why should the encoder/connector care
if the lane is reversed or not ?
Benjamin Tissoires Aug. 26, 2015, 2:29 p.m. UTC | #5
On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote:
> 
> 
> On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:
> >On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
> >>On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
> >><benjamin.tissoires@redhat.com> wrote:
> >>>On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>>>
> >>>>On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
> >>>>>On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
> >>>>>>why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
> >>>>>>identify both lane count and reversal state without touching anything in the
> >>>>>>link training code. i am yet to upstream my changes for CHT that i can share
> >>>>>>if required that does the same in intel_dp_detect without touching any line
> >>>>>>in link training path.
> >>>>>With my current limited knowledge of the dp hotplug (and i915 driver) I
> >>>>>am not sure we could detect the reversed state without trying to train 1
> >>>>>lane only. I'd be glad to look at your changes and test them on my
> >>>>>system if you think that could help having a cleaner solution.
> >>>>>
> >>>>>Cheers,
> >>>>>Benjamin
> >>>>No, what i recommended was to do link training but in intel_dp_detect. Since
> >>>>USB Type C cable
> >>>>also has its own lane count restriction (it can have different lane count
> >>>>than the one supported
> >>>>by panel) you might have to figure that out as well. so both reversal and
> >>>>lane count detection
> >>>>can be done outside the modeset path and keep the code free of type C
> >>>>changes outside
> >>>>detection path.
> >>>>
> >>>>Please find below the code to do the same. Do not waste time trying to apply
> >>>>this directly on
> >>>>nightly since this is based on a local tree and because this is pre- atomic
> >>>>changes code, so you
> >>>>might have to modify chv_upfront_link_train to work on top of the latest
> >>>>nightly code. we
> >>>>are supposed to upstream this and is in my todo list.
> >>>>
> >>>[original patch snipped...]
> >>>
> >>>Hi Sivakumar,
> >>>
> >>>So I managed to manually re-apply your patch on top of
> >>>drm-intel-nightly, and tried to port it to make Broadwell working too.
> >>>It works OK if the system is already boot without any external DP used.
> >>>In this case, the detection works and I can see my external monitor
> >>>working properly.
> >>>
> >>>However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
> >>>understand why. I think I enabled all that is mentioned in the PRM to be
> >>>able to train the DP link, but I am obviously missing something else.
> >>>Can you have a look?
> >>>
> >>Hi Benjamin,
> >>
> >>I would recommend against this approach. Some adapters will claim that
> >>they recovered a clock even when it isn't on the lanes you enabled,
> >>which means that the reversal detection doesn't always work. The only
> >>reliable way to do this is to go talk to the Chrome OS EC (you can
> >>find these patches later in the Chrome OS tree). It's not as generic,
> >>but we might be able to abstract that logic, maybe.
> >>
> >Hi Stéphane,
> >
> >This is a very good news. I was afraid we would not have access to the
> >hardware controller because the Intel controller hub spec was not
> >public.
> >
> >I will try to have a look at it, but the latest chromeos branch (3.18)
> >seems to differ quite a lot from the upstream one. Anyway, fingers
> >crossed.
> >
> >Cheers,
> >Benjamin
> Hi Benjamin/Stéphan,

Hi Sivakumar,

>     All Intel platforms (at-least those i inquired about) handle lane
> reversal in HW.

That is the theory and what is written in the USB Type C spec IIRC.
Problem is, the Chromebook Pixel 2 external display does not work when a
USB Type-C adapter is in the reversed position (or believe me, I would
definitively not have submitted a patch for the beauty of it).
Everything else works (link training when 4 lanes are activated, or
other communication channels). Only the order of the 4 data lanes
matters in this situation and the USB controller does not reverse them
for us on this laptop.

> your statement that link training will pass even on reversed lane seems to
> point
> to the same fact. in such a scenario why should the encoder/connector care
> if the lane is reversed or not ?

Problem is that Stephane said some adapters are lying regarding the
clock recovery. They claim everything is fine while in the end, the
display doesn't show anything because the lanes are reversed. If this is
just a chromebook Pixel 2 issue, that's better then. I won't have to try
to put some generic interface to notify that the display port lanes have
to be reversed.

Cheers,
Benjamin

> 
> -- 
> regards,
> Sivakumar
>
Sivakumar Thulasimani Aug. 27, 2015, 5:24 a.m. UTC | #6
On 8/26/2015 7:59 PM, Benjamin Tissoires wrote:
> On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>
>> On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:
>>> On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:
>>>> On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
>>>> <benjamin.tissoires@redhat.com> wrote:
>>>>> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>>>>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>>>>>>> On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>>>>>>> why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
>>>>>>>> identify both lane count and reversal state without touching anything in the
>>>>>>>> link training code. i am yet to upstream my changes for CHT that i can share
>>>>>>>> if required that does the same in intel_dp_detect without touching any line
>>>>>>>> in link training path.
>>>>>>> With my current limited knowledge of the dp hotplug (and i915 driver) I
>>>>>>> am not sure we could detect the reversed state without trying to train 1
>>>>>>> lane only. I'd be glad to look at your changes and test them on my
>>>>>>> system if you think that could help having a cleaner solution.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Benjamin
>>>>>> No, what i recommended was to do link training but in intel_dp_detect. Since
>>>>>> USB Type C cable
>>>>>> also has its own lane count restriction (it can have different lane count
>>>>>> than the one supported
>>>>>> by panel) you might have to figure that out as well. so both reversal and
>>>>>> lane count detection
>>>>>> can be done outside the modeset path and keep the code free of type C
>>>>>> changes outside
>>>>>> detection path.
>>>>>>
>>>>>> Please find below the code to do the same. Do not waste time trying to apply
>>>>>> this directly on
>>>>>> nightly since this is based on a local tree and because this is pre- atomic
>>>>>> changes code, so you
>>>>>> might have to modify chv_upfront_link_train to work on top of the latest
>>>>>> nightly code. we
>>>>>> are supposed to upstream this and is in my todo list.
>>>>>>
>>>>> [original patch snipped...]
>>>>>
>>>>> Hi Sivakumar,
>>>>>
>>>>> So I managed to manually re-apply your patch on top of
>>>>> drm-intel-nightly, and tried to port it to make Broadwell working too.
>>>>> It works OK if the system is already boot without any external DP used.
>>>>> In this case, the detection works and I can see my external monitor
>>>>> working properly.
>>>>>
>>>>> However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
>>>>> understand why. I think I enabled all that is mentioned in the PRM to be
>>>>> able to train the DP link, but I am obviously missing something else.
>>>>> Can you have a look?
>>>>>
>>>> Hi Benjamin,
>>>>
>>>> I would recommend against this approach. Some adapters will claim that
>>>> they recovered a clock even when it isn't on the lanes you enabled,
>>>> which means that the reversal detection doesn't always work. The only
>>>> reliable way to do this is to go talk to the Chrome OS EC (you can
>>>> find these patches later in the Chrome OS tree). It's not as generic,
>>>> but we might be able to abstract that logic, maybe.
>>>>
>>> Hi Stéphane,
>>>
>>> This is a very good news. I was afraid we would not have access to the
>>> hardware controller because the Intel controller hub spec was not
>>> public.
>>>
>>> I will try to have a look at it, but the latest chromeos branch (3.18)
>>> seems to differ quite a lot from the upstream one. Anyway, fingers
>>> crossed.
>>>
>>> Cheers,
>>> Benjamin
>> Hi Benjamin/Stéphan,
> Hi Sivakumar,
>
>>      All Intel platforms (at-least those i inquired about) handle lane
>> reversal in HW.
> That is the theory and what is written in the USB Type C spec IIRC.
> Problem is, the Chromebook Pixel 2 external display does not work when a
> USB Type-C adapter is in the reversed position (or believe me, I would
> definitively not have submitted a patch for the beauty of it).
> Everything else works (link training when 4 lanes are activated, or
> other communication channels). Only the order of the 4 data lanes
> matters in this situation and the USB controller does not reverse them
> for us on this laptop.
>> your statement that link training will pass even on reversed lane seems to
>> point
>> to the same fact. in such a scenario why should the encoder/connector care
>> if the lane is reversed or not ?
> Problem is that Stephane said some adapters are lying regarding the
> clock recovery. They claim everything is fine while in the end, the
> display doesn't show anything because the lanes are reversed. If this is
> just a chromebook Pixel 2 issue, that's better then. I won't have to try
> to put some generic interface to notify that the display port lanes have
> to be reversed.
>
> Cheers,
> Benjamin
Thanks for the info :). There is no way in code to confirm if after link 
training display
is working properly (other than short pulse for link related issues)
so this has to be on a case by case basis. i would recommend
if you plan to upstream it to restrict the changes for chromebook Pixel 
2 alone.
>> -- 
>> regards,
>> Sivakumar
>>

Patch
diff mbox

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 818f3a3..e8ddba0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15799,3 +15799,166 @@  void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
 		spin_unlock_irq(&dev->event_lock);
 	}
 }
+
+static bool
+intel_upfront_link_train_config(struct drm_device *dev,
+				struct intel_dp *intel_dp,
+				struct intel_crtc *crtc,
+				uint8_t link_bw,
+				uint8_t lane_count)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct intel_connector *connector = intel_dp->attached_connector;
+	struct intel_encoder *encoder = connector->encoder;
+	bool success;
+
+	intel_dp->link_bw = link_bw;
+	intel_dp->lane_count = lane_count;
+
+	/* Find port clock from link_bw */
+	crtc->config->port_clock = drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
+
+	/* Enable PLL followed by port */
+	if (IS_BROADWELL(dev)) {
+		hsw_dp_set_ddi_pll_sel(crtc->config, intel_dp->link_bw);
+		if (intel_crtc_to_shared_dpll(crtc))
+			intel_enable_shared_dpll(crtc);
+
+		intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
+
+	} else if (IS_CHERRYVIEW(dev)) {
+		intel_dp_set_clock(encoder, crtc->config, intel_dp->link_bw);
+		if (encoder->pre_pll_enable)
+			encoder->pre_pll_enable(encoder);
+		if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+			chv_enable_pll(crtc, crtc->config);
+	}
+	if (encoder->pre_enable)
+		encoder->pre_enable(encoder);
+
+	success = intel_dp->train_set_valid;
+
+	/* Reset encoder for next retry or for clean up */
+	if (encoder->post_disable)
+		encoder->post_disable(encoder);
+	if (IS_CHERRYVIEW(dev)) {
+		if (!intel_pipe_has_type(crtc, INTEL_OUTPUT_DSI))
+			chv_disable_pll(dev_priv, crtc->pipe);
+	} else if (IS_BROADWELL(dev)) {
+		intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
+		if (intel_crtc_to_shared_dpll(crtc))
+			intel_disable_shared_dpll(crtc);
+	}
+
+	intel_dp->train_set_valid = false;
+
+	return success;
+}
+
+bool
+intel_upfront_link_train(struct drm_device *dev,
+			 struct intel_dp *intel_dp,
+			 struct intel_crtc *crtc)
+{
+	struct intel_connector *connector = intel_dp->attached_connector;
+	struct intel_encoder *encoder = connector->encoder;
+	struct intel_digital_port *intel_dig_port = enc_to_dig_port(&encoder->base);
+	uint8_t link_bw, lane_count;
+	bool found = false;
+	bool valid_crtc = !!crtc;
+
+	if (!connector || !encoder) {
+		DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
+		return false;
+	}
+
+	/* Find an unused crtc and use it for link training if no crtc is given */
+	if (!crtc) {
+		for_each_intel_crtc(dev, crtc) {
+			if (intel_crtc_active(&crtc->base))
+				continue;
+
+			/* Make sure the new crtc will work with the encoder */
+			if (!drm_encoder_crtc_ok(&encoder->base, &crtc->base))
+				continue;
+
+			encoder->base.crtc = &crtc->base;
+
+			found = true;
+			break;
+		}
+
+		if (!found) {
+			DRM_ERROR("Could not find crtc for upfront link training\n");
+			goto exit;
+		}
+	}
+
+	DRM_DEBUG_KMS("upfront link training on pipe:%c\n",
+		      pipe_name(crtc->pipe));
+
+	/* check the reversed state of the adapter first */
+
+	/* unset the reversal bit */
+	intel_dig_port->saved_port_bits &= ~DDI_BUF_PORT_REVERSAL;
+
+	/* Initialize with Max Link rate supported by panel & one lane */
+	intel_dp->link_bw = intel_dp->dpcd[DP_MAX_LINK_RATE];
+	intel_dp->lane_count = 1;
+
+	/* Check if link training passed; if not, update the reversed state */
+	if (!intel_upfront_link_train_config(dev, intel_dp, crtc,
+					intel_dp->dpcd[DP_MAX_LINK_RATE], 1))
+		intel_dig_port->saved_port_bits |= DDI_BUF_PORT_REVERSAL;
+
+	found = false;
+
+	/* Initialize with Max Link rate & lane count supported by panel */
+	link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
+	lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] & DP_MAX_LANE_COUNT_MASK;
+
+	do {
+		/* Check if link training passed; if so update lane count */
+		if (intel_upfront_link_train_config(dev, intel_dp, crtc,
+					link_bw, lane_count)) {
+			intel_dp->dpcd[DP_MAX_LANE_COUNT] &=
+						~DP_MAX_LANE_COUNT_MASK;
+			intel_dp->dpcd[DP_MAX_LANE_COUNT] |=
+				intel_dp->lane_count & DP_MAX_LANE_COUNT_MASK;
+
+			found = true;
+			goto exit;
+		}
+
+		DRM_DEBUG_KMS("upfront link training failed. lanes:%d bw:%d\n",
+				intel_dp->lane_count, intel_dp->link_bw);
+
+		/* Go down to the next level and retry link training */
+		if (lane_count == 4) {
+			lane_count = 2;
+		} else if (lane_count == 2) {
+			lane_count = 1;
+		} else if (link_bw == DP_LINK_BW_5_4) {
+			link_bw = DP_LINK_BW_2_7;
+			lane_count = 4;
+		} else if (link_bw == DP_LINK_BW_2_7) {
+			link_bw = DP_LINK_BW_1_62;
+			lane_count = 4;
+		} else {
+			/* Tried all combinations, so exit */
+			break;
+		}
+
+	} while (1);
+
+exit:
+	/* Clear local associations made */
+	if (!valid_crtc)
+		encoder->base.crtc = NULL;
+
+	if (found)
+		DRM_DEBUG_KMS("upfront link training passed. lanes:%d bw:%d\n",
+				intel_dp->lane_count, intel_dp->link_bw);
+
+	return found;
+}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..187800b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1144,7 +1144,7 @@  skl_edp_set_pll_config(struct intel_crtc_state *pipe_config, int link_clock)
 	pipe_config->dpll_hw_state.ctrl1 = ctrl1;
 }
 
-static void
+void
 hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw)
 {
 	memset(&pipe_config->dpll_hw_state, 0,
@@ -1202,7 +1202,7 @@  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 		return (DP_LINK_BW_2_7 >> 3) + 1;
 }
 
-static void
+void
 intel_dp_set_clock(struct intel_encoder *encoder,
 		   struct intel_crtc_state *pipe_config, int link_bw)
 {
@@ -4423,6 +4423,10 @@  g4x_dp_detect(struct intel_dp *intel_dp)
 	else if (ret == 0)
 		return connector_status_disconnected;
 
+	/* Avoid DPCD opertations if status is same */
+	if (intel_dp->attached_connector->base.status == connector_status_connected)
+		return connector_status_connected;
+
 	return intel_dp_detect_dpcd(intel_dp);
 }
 
@@ -4495,7 +4499,9 @@  intel_dp_detect(struct drm_connector *connector, bool force)
 	struct intel_dp *intel_dp = intel_attached_dp(connector);
 	struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
 	struct intel_encoder *intel_encoder = &intel_dig_port->base;
+	struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
 	struct drm_device *dev = connector->dev;
+	struct intel_crtc *intel_crtc;
 	enum drm_connector_status status;
 	enum intel_display_power_domain power_domain;
 	bool ret;
@@ -4540,6 +4546,18 @@  intel_dp_detect(struct drm_connector *connector, bool force)
 
 	if (intel_encoder->type != INTEL_OUTPUT_EDP)
 		intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+
+	if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT &&
+	    (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))) {
+		/* Do not handle connected boot scenario where panel is enabled
+		 * by GOP/VBIOS.
+		 */
+		if ((connector->status != connector_status_connected) &&
+		    !(intel_encoder->connectors_active &&
+		      crtc && crtc->enabled))
+			intel_upfront_link_train(dev, intel_dp, NULL);
+	}
+
 	status = connector_status_connected;
 
 	/* Try to read the source of the interrupt */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..fcc95d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1163,6 +1163,13 @@  bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_complete_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+bool intel_upfront_link_train(struct drm_device *dev,
+			      struct intel_dp *intel_dp,
+			      struct intel_crtc *crtc);
+void hsw_dp_set_ddi_pll_sel(struct intel_crtc_state *pipe_config, int link_bw);
+void intel_dp_set_clock(struct intel_encoder *encoder,
+			struct intel_crtc_state *pipe_config, int link_bw);
+
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
 void intel_dp_encoder_destroy(struct drm_encoder *encoder);
 int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);