Date:	Thu, 06 Aug 2015 15:11:45 +0530
From:	Sivakumar Thulasimani <sivakumar.thulasimani@...el.com>
To:	Benjamin Tissoires <benjamin.tissoires@...hat.com>
CC:	Daniel Vetter <daniel.vetter@...el.com>,
	intel-gfx@...ts.freedesktop.org, Todd Broch <tbroch@...omium.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for
 DP



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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists