Re: [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

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

 





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);

--
regards,
Sivakumar

_______________________________________________
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