[RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Durgadoss R]

This is an RFC series to start the review/discussion on approach
to support USB type C based DP panel.

To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the 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.

The goal is to find out the number of lanes which can be supported
using a particular cable so that we can cap 'max_available_lanes'
to that number during modeset.

These two patches are based on 4.2-rc2 and tested only on
a BXT A1 platform for now.

Brief summary of the approach taken:
-----------------------------------
1.As soon as DP-hotplug is detected, driver starts link training
  with highest number of lanes/bandwidth possible. If it fails,
  driver retries link training with lane/2 for same bandwidth.
  We continue this procedure until we find a working configuration
  of lane/bandwidth values. This 'number of lanes' is then
  set as the 'max_available_lanes', so that the following
  intel_dp_compute_config() during modeset picks it up as
  max_lane_count (instead of 4 always, from DPCD).

2.Since we do only link training on hotplug, only the port
  and its PLLs are enabled/disabled without touching pipe/
  planes etc.

3.For scenarios where we boot with DP connected (along with
  an LFP like MIPI/eDP) we disable the crtc and then start
  link training, since BIOS brings up DP. The crtc is
  enabled back during subsequent modeset. This needs some
  changes for latest -nightly branch since we do not have
  intel_crtc_control() anymore.

4.Since we are doing the link training on hotplug (as
  opposed to during modeset) we named the function
  '{chv/bxt/*}_upfront_link_train'. We can also think
  of a virtual func for this, inside intel_encoder.

Durgadoss R (2):
  drm/i915/dp: Make bxt_ddi_pll_select non-static
  drm/i915/dp: Enable Upfront link training for type-C DP support

 drivers/gpu/drm/i915/intel_ddi.c     |  11 +--
 drivers/gpu/drm/i915/intel_display.c | 130 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_dp.c      |  22 ++++++
 drivers/gpu/drm/i915/intel_drv.h     |   6 ++
 4 files changed, 165 insertions(+), 4 deletions(-)

-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 1/2] drm/i915/dp: Make bxt_ddi_pll_select non-static

[Durgadoss R]

Make bxt_ddi_pll_select non-static so that it can
be called from other files also. The subsequent
patches need this from display.c.

The call to 'intel_get_shared_pll' is not required
if there is already a valid PLL. This patch adds
a boolean argument to by-pass this case.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/gpu/drm/i915/intel_ddi.c | 11 +++++++----
 drivers/gpu/drm/i915/intel_drv.h |  4 ++++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 4823184..5326d60 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1612,10 +1612,9 @@ static const struct bxt_clk_div bxt_dp_clk_val[] = {
 	{432000, 3, 1, 32, 1677722, 1, 1}
 };
 
-static bool
-bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
+bool bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
 		   struct intel_crtc_state *crtc_state,
-		   struct intel_encoder *intel_encoder)
+		   struct intel_encoder *intel_encoder, bool find_pll)
 {
 	struct intel_shared_dpll *pll;
 	struct bxt_clk_div clk_div = {0};
@@ -1724,6 +1723,9 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
 	crtc_state->dpll_hw_state.pcsdw12 =
 		LANESTAGGER_STRAP_OVRD | lanestagger;
 
+	if (!find_pll)
+		goto exit;
+
 	pll = intel_get_shared_dpll(intel_crtc, crtc_state);
 	if (pll == NULL) {
 		DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
@@ -1734,6 +1736,7 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
 	/* shared DPLL id 0 is DPLL A */
 	crtc_state->ddi_pll_sel = pll->id;
 
+exit:
 	return true;
 }
 
@@ -1756,7 +1759,7 @@ bool intel_ddi_pll_select(struct intel_crtc *intel_crtc,
 					  intel_encoder);
 	else if (IS_BROXTON(dev))
 		return bxt_ddi_pll_select(intel_crtc, crtc_state,
-					  intel_encoder);
+					  intel_encoder, true);
 	else
 		return hsw_ddi_pll_select(intel_crtc, crtc_state,
 					  intel_encoder);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 46484e4..30f91cf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1130,6 +1130,10 @@ void broxton_init_cdclk(struct drm_device *dev);
 void broxton_uninit_cdclk(struct drm_device *dev);
 void broxton_ddi_phy_init(struct drm_device *dev);
 void broxton_ddi_phy_uninit(struct drm_device *dev);
+bool bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
+		   struct intel_crtc_state *crtc_state,
+		   struct intel_encoder *intel_encoder,
+		   bool find_pll);
 void bxt_enable_dc9(struct drm_i915_private *dev_priv);
 void bxt_disable_dc9(struct drm_i915_private *dev_priv);
 void skl_init_cdclk(struct drm_i915_private *dev_priv);
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

[Durgadoss R]

To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the 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 that fails, the driver
falls back to x2 lanes; and repeats this procedure for all
bandwidth/lane configurations.

* Since link training is done before modeset only the port
  (and not pipe/planes) and its associated PLLs are enabled.
* Once link training is done, the port and its PLLs are disabled;
  so that the subsequent modeset is not aware of these changes.
* On DP hotplug: Directly start link training on the crtc
  associated with the DP encoder.
* On Connected boot scenarios: When booted with an LFP and a DP,
  typically, BIOS brings up DP. In these cases, we disable the
  crtc first and then start upfront link training. The crtc is
  re-enabled as part of a subsequent modeset.
* For BXT, ddi->enable/disable for DP only enable/disable
  audio codec and hence are not included in upfront link
  training sequence.
* As of now, this is tested only on BXT A1 platform, on
  kernel 4.2-rc2.

Signed-off-by: Durgadoss R <durgadoss.r@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 130 +++++++++++++++++++++++++++++++++++
 drivers/gpu/drm/i915/intel_dp.c      |  22 ++++++
 drivers/gpu/drm/i915/intel_drv.h     |   2 +
 3 files changed, 154 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e629a1b..bbcb5fa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15638,3 +15638,133 @@ void intel_modeset_preclose(struct drm_device *dev, struct drm_file *file)
 		spin_unlock_irq(&dev->event_lock);
 	}
 }
+
+bool bxt_upfront_link_train(struct drm_device *dev,
+		struct intel_dp *intel_dp, struct intel_crtc *crtc)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+	struct intel_connector *connector = intel_dp->attached_connector;
+	struct intel_encoder *encoder = connector->encoder;
+	struct intel_shared_dpll *pll;
+	bool ret, found, valid_crtc = false;
+
+	if (!connector || !encoder) {
+		DRM_DEBUG_KMS("dp connector/encoder is NULL\n");
+		return false;
+	}
+
+	/* If we already have a crtc, start link training directly */
+	if (crtc) {
+		valid_crtc = true;
+		goto start_link_train;
+	}
+
+	/* Find an unused crtc and use it for link training */
+	for_each_intel_crtc(dev, crtc) {
+		if (intel_crtc_active(&crtc->base))
+			continue;
+
+		connector->new_encoder = encoder;
+		encoder->new_crtc = crtc;
+		encoder->base.crtc = &crtc->base;
+
+		/* Make sure the new crtc will work with the encoder */
+		if (drm_encoder_crtc_ok(&encoder->base,
+					 &crtc->base)) {
+			found = true;
+			break;
+		}
+	}
+
+	if (!found) {
+		DRM_ERROR("Could not find crtc for upfront link training\n");
+		return false;
+	}
+
+start_link_train:
+
+	DRM_ERROR("upfront link training on pipe:%c\n",
+					pipe_name(crtc->pipe));
+	found = false;
+
+	/* Initialize with Max Link rate & lane count supported by panel */
+	intel_dp->link_bw =  intel_dp->dpcd[DP_MAX_LINK_RATE];
+	intel_dp->lane_count = intel_dp->dpcd[DP_MAX_LANE_COUNT] &
+					DP_MAX_LANE_COUNT_MASK;
+
+	/* Selects the shared DPLL to use for this port */
+	bxt_get_ddi_pll(dev_priv, dig_port->port, crtc->config);
+	pll = intel_crtc_to_shared_dpll(crtc);
+
+	do {
+		/* Find port clock from link_bw */
+		crtc->config->port_clock =
+				drm_dp_bw_code_to_link_rate(intel_dp->link_bw);
+
+		ret = bxt_ddi_pll_select(crtc, crtc->config, encoder, false);
+		if (!ret) {
+			DRM_ERROR("Could not find PLL..exiting\n");
+			goto exit;
+		}
+
+		pll->config.crtc_mask = (1 << crtc->pipe);
+		pll->config.hw_state = crtc->config->dpll_hw_state;
+
+		DRM_DEBUG_KMS("Using shared_dpll:%d\n", crtc->config->shared_dpll);
+
+		/* Enable PLL followed by port */
+		intel_enable_shared_dpll(crtc);
+		encoder->pre_enable(encoder);
+
+		/* Check if link training passed; if so update lane count */
+		if (intel_dp->train_set_valid) {
+			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;
+		}
+
+		/* Disable port followed by PLL for next retry/clean up */
+		encoder->post_disable(encoder);
+		intel_disable_shared_dpll(crtc);
+
+		if (found)
+			goto exit;
+
+		DRM_ERROR("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 (intel_dp->lane_count == 4) {
+			intel_dp->lane_count = 2;
+		} else if (intel_dp->lane_count == 2) {
+			intel_dp->lane_count = 1;
+		} else if (intel_dp->link_bw == DP_LINK_BW_5_4) {
+			intel_dp->link_bw = DP_LINK_BW_2_7;
+			intel_dp->lane_count = 4;
+		} else if (intel_dp->link_bw == DP_LINK_BW_2_7) {
+			intel_dp->link_bw = DP_LINK_BW_1_62;
+			intel_dp->lane_count = 4;
+		} else {
+			/* Tried all combinations, so exit */
+			break;
+		}
+
+	} while (1);
+
+exit:
+	/* Clear local associations made */
+	if (!valid_crtc) {
+		connector->new_encoder = NULL;
+		encoder->new_crtc = NULL;
+		encoder->base.crtc = NULL;
+	}
+
+	if (found)
+		DRM_ERROR("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 45ab25e..e103b67 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4784,8 +4784,10 @@ 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 drm_crtc *crtc = intel_dig_port->base.base.crtc;
 	struct intel_encoder *intel_encoder = &intel_dig_port->base;
 	struct drm_device *dev = connector->dev;
+	struct intel_crtc *intel_crtc = NULL;
 	enum drm_connector_status status;
 	enum intel_display_power_domain power_domain;
 	bool ret;
@@ -4830,6 +4832,26 @@ intel_dp_detect(struct drm_connector *connector, bool force)
 
 	if (intel_encoder->type != INTEL_OUTPUT_EDP)
 		intel_encoder->type = INTEL_OUTPUT_DISPLAYPORT;
+
+	/*
+	 * On hotplug cases, we call _upfront_link_train directly.
+	 * In connected boot scenarios (boot with {MIPI/eDP} + DP),
+	 * BIOS typically brings up DP. Hence, we disable the crtc
+	 * to do _upfront_link_training. It gets re-enabled as part of
+	 * subsequent modeset.
+	 */
+	if (IS_BROXTON(dev) && intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT) {
+		if (intel_encoder->connectors_active && crtc && crtc->enabled) {
+			intel_crtc = to_intel_crtc(crtc);
+			DRM_ERROR("Disabling crtc %c for upfront link training\n",
+					pipe_name(intel_crtc->pipe));
+			intel_crtc_control(crtc, false);
+		}
+		ret = bxt_upfront_link_train(dev, intel_dp, intel_crtc);
+		if (!ret)
+			goto out;
+	}
+
 	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 30f91cf..55d6e12 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1134,6 +1134,8 @@ bool bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
 		   struct intel_crtc_state *crtc_state,
 		   struct intel_encoder *intel_encoder,
 		   bool find_pll);
+bool bxt_upfront_link_train(struct drm_device *dev,
+			struct intel_dp *intel_dp, struct intel_crtc *crtc);
 void bxt_enable_dc9(struct drm_i915_private *dev_priv);
 void bxt_disable_dc9(struct drm_i915_private *dev_priv);
 void skl_init_cdclk(struct drm_i915_private *dev_priv);
-- 
1.9.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Jani Nikula]

On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
> This is an RFC series to start the review/discussion on approach
> to support USB type C based DP panel.
>
> To support USB type C alternate DP mode, the display driver needs to
> know the number of lanes required by the 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.
>
> The goal is to find out the number of lanes which can be supported
> using a particular cable so that we can cap 'max_available_lanes'
> to that number during modeset.
>
> These two patches are based on 4.2-rc2 and tested only on
> a BXT A1 platform for now.
>
> Brief summary of the approach taken:
> -----------------------------------
> 1.As soon as DP-hotplug is detected, driver starts link training
>   with highest number of lanes/bandwidth possible. If it fails,
>   driver retries link training with lane/2 for same bandwidth.
>   We continue this procedure until we find a working configuration
>   of lane/bandwidth values. This 'number of lanes' is then
>   set as the 'max_available_lanes', so that the following
>   intel_dp_compute_config() during modeset picks it up as
>   max_lane_count (instead of 4 always, from DPCD).

Would all of this work automatically if our link training sequence
followed the DP spec to the letter wrt degrading the link on failures?

BR,
Jani.


>
> 2.Since we do only link training on hotplug, only the port
>   and its PLLs are enabled/disabled without touching pipe/
>   planes etc.
>
> 3.For scenarios where we boot with DP connected (along with
>   an LFP like MIPI/eDP) we disable the crtc and then start
>   link training, since BIOS brings up DP. The crtc is
>   enabled back during subsequent modeset. This needs some
>   changes for latest -nightly branch since we do not have
>   intel_crtc_control() anymore.
>
> 4.Since we are doing the link training on hotplug (as
>   opposed to during modeset) we named the function
>   '{chv/bxt/*}_upfront_link_train'. We can also think
>   of a virtual func for this, inside intel_encoder.
>
> Durgadoss R (2):
>   drm/i915/dp: Make bxt_ddi_pll_select non-static
>   drm/i915/dp: Enable Upfront link training for type-C DP support
>
>  drivers/gpu/drm/i915/intel_ddi.c     |  11 +--
>  drivers/gpu/drm/i915/intel_display.c | 130 +++++++++++++++++++++++++++++++++++
>  drivers/gpu/drm/i915/intel_dp.c      |  22 ++++++
>  drivers/gpu/drm/i915/intel_drv.h     |   6 ++
>  4 files changed, 165 insertions(+), 4 deletions(-)
>
> -- 
> 1.9.1
>

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Jani,

>-----Original Message-----
>From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
>Sent: Wednesday, September 16, 2015 3:18 PM
>To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>Cc: R, Durgadoss
>Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
>> This is an RFC series to start the review/discussion on approach
>> to support USB type C based DP panel.
>>
>> To support USB type C alternate DP mode, the display driver needs to
>> know the number of lanes required by the 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.
>>
>> The goal is to find out the number of lanes which can be supported
>> using a particular cable so that we can cap 'max_available_lanes'
>> to that number during modeset.
>>
>> These two patches are based on 4.2-rc2 and tested only on
>> a BXT A1 platform for now.
>>
>> Brief summary of the approach taken:
>> -----------------------------------
>> 1.As soon as DP-hotplug is detected, driver starts link training
>>   with highest number of lanes/bandwidth possible. If it fails,
>>   driver retries link training with lane/2 for same bandwidth.
>>   We continue this procedure until we find a working configuration
>>   of lane/bandwidth values. This 'number of lanes' is then
>>   set as the 'max_available_lanes', so that the following
>>   intel_dp_compute_config() during modeset picks it up as
>>   max_lane_count (instead of 4 always, from DPCD).
>
>Would all of this work automatically if our link training sequence
>followed the DP spec to the letter wrt degrading the link on failures?

That is one part of it.

Our intention is also to filter out the modes that cannot be set
with 'max_available_lanes' through connector->mode_valid
callback, which uses these variables. Otherwise, we risk failing
a modeset that uses higher resolutions than possible.

Sorry, I should have also added this as part of the commit message.

Thanks,
Durga

>
>BR,
>Jani.
>
>
>>
>> 2.Since we do only link training on hotplug, only the port
>>   and its PLLs are enabled/disabled without touching pipe/
>>   planes etc.
>>
>> 3.For scenarios where we boot with DP connected (along with
>>   an LFP like MIPI/eDP) we disable the crtc and then start
>>   link training, since BIOS brings up DP. The crtc is
>>   enabled back during subsequent modeset. This needs some
>>   changes for latest -nightly branch since we do not have
>>   intel_crtc_control() anymore.
>>
>> 4.Since we are doing the link training on hotplug (as
>>   opposed to during modeset) we named the function
>>   '{chv/bxt/*}_upfront_link_train'. We can also think
>>   of a virtual func for this, inside intel_encoder.
>>
>> Durgadoss R (2):
>>   drm/i915/dp: Make bxt_ddi_pll_select non-static
>>   drm/i915/dp: Enable Upfront link training for type-C DP support
>>
>>  drivers/gpu/drm/i915/intel_ddi.c     |  11 +--
>>  drivers/gpu/drm/i915/intel_display.c | 130 +++++++++++++++++++++++++++++++++++
>>  drivers/gpu/drm/i915/intel_dp.c      |  22 ++++++
>>  drivers/gpu/drm/i915/intel_drv.h     |   6 ++
>>  4 files changed, 165 insertions(+), 4 deletions(-)
>>
>> --
>> 1.9.1
>>
>
>--
>Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Daniel Vetter]

On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
> Hi Jani,
> 
> >-----Original Message-----
> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> >Sent: Wednesday, September 16, 2015 3:18 PM
> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
> >Cc: R, Durgadoss
> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >
> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
> >> This is an RFC series to start the review/discussion on approach
> >> to support USB type C based DP panel.
> >>
> >> To support USB type C alternate DP mode, the display driver needs to
> >> know the number of lanes required by the 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.
> >>
> >> The goal is to find out the number of lanes which can be supported
> >> using a particular cable so that we can cap 'max_available_lanes'
> >> to that number during modeset.
> >>
> >> These two patches are based on 4.2-rc2 and tested only on
> >> a BXT A1 platform for now.
> >>
> >> Brief summary of the approach taken:
> >> -----------------------------------
> >> 1.As soon as DP-hotplug is detected, driver starts link training
> >>   with highest number of lanes/bandwidth possible. If it fails,
> >>   driver retries link training with lane/2 for same bandwidth.
> >>   We continue this procedure until we find a working configuration
> >>   of lane/bandwidth values. This 'number of lanes' is then
> >>   set as the 'max_available_lanes', so that the following
> >>   intel_dp_compute_config() during modeset picks it up as
> >>   max_lane_count (instead of 4 always, from DPCD).
> >
> >Would all of this work automatically if our link training sequence
> >followed the DP spec to the letter wrt degrading the link on failures?
> 
> That is one part of it.
> 
> Our intention is also to filter out the modes that cannot be set
> with 'max_available_lanes' through connector->mode_valid
> callback, which uses these variables. Otherwise, we risk failing
> a modeset that uses higher resolutions than possible.
> 
> Sorry, I should have also added this as part of the commit message.

One approach to implement DP link training to the spec is that if things
fail we enable the pipe anyway (since anything else would seriously
surprise userspace, especially for async modesets, and lead to hangs in
userspace if vblank interrupts don't happen). And then we generate a
hotplug event to inform userspace that something change with the monitor
configuration, to give userspace a chance to look at the filtered mode
list and select a new config it likes.

That approach would fit rather well into the overall framework of how
detection/mode-config changes are done currently by keeping all the policy
for selecting the precise mode config in userspace. Downside is that for
usb type-C it would cause flicker since if we only have 2 lanes we'll
always first try the high-res mode and fail. So I think in the end we need
both approaches. Wrt the rfc it would be great if we can make it at least
somewhat platform-agnostic - anything on big core since hsw+ supports
enabling the DP port without enabling a pipe (because dp mst needs that),
so could support your approach here too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Daniel,

Thanks for having a look at it..

>-----Original Message-----
>From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Wednesday, September 23, 2015 3:14 PM
>To: R, Durgadoss
>Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
>> Hi Jani,
>>
>> >-----Original Message-----
>> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
>> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >Cc: R, Durgadoss
>> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >
>> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
>> >> This is an RFC series to start the review/discussion on approach
>> >> to support USB type C based DP panel.
>> >>
>> >> To support USB type C alternate DP mode, the display driver needs to
>> >> know the number of lanes required by the 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.
>> >>
>> >> The goal is to find out the number of lanes which can be supported
>> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> to that number during modeset.
>> >>
>> >> These two patches are based on 4.2-rc2 and tested only on
>> >> a BXT A1 platform for now.
>> >>
>> >> Brief summary of the approach taken:
>> >> -----------------------------------
>> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >>   driver retries link training with lane/2 for same bandwidth.
>> >>   We continue this procedure until we find a working configuration
>> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >>   set as the 'max_available_lanes', so that the following
>> >>   intel_dp_compute_config() during modeset picks it up as
>> >>   max_lane_count (instead of 4 always, from DPCD).
>> >
>> >Would all of this work automatically if our link training sequence
>> >followed the DP spec to the letter wrt degrading the link on failures?
>>
>> That is one part of it.
>>
>> Our intention is also to filter out the modes that cannot be set
>> with 'max_available_lanes' through connector->mode_valid
>> callback, which uses these variables. Otherwise, we risk failing
>> a modeset that uses higher resolutions than possible.
>>
>> Sorry, I should have also added this as part of the commit message.
>
>One approach to implement DP link training to the spec is that if things
>fail we enable the pipe anyway (since anything else would seriously
>surprise userspace, especially for async modesets, and lead to hangs in
>userspace if vblank interrupts don't happen). And then we generate a
>hotplug event to inform userspace that something change with the monitor
>configuration, to give userspace a chance to look at the filtered mode
>list and select a new config it likes.
>
>That approach would fit rather well into the overall framework of how
>detection/mode-config changes are done currently by keeping all the policy
>for selecting the precise mode config in userspace. Downside is that for
>usb type-C it would cause flicker since if we only have 2 lanes we'll
>always first try the high-res mode and fail. So I think in the end we need

Yes, agreed.

>both approaches. Wrt the rfc it would be great if we can make it at least
>somewhat platform-agnostic - anything on big core since hsw+ supports

By platform-agnostic,

do you mean to try and implement _upfront_link_train() 
for few more platforms since HSW+ to see how we can re-use common code
if any ?

If it is something else, please elaborate a bit more..

>enabling the DP port without enabling a pipe (because dp mst needs that),
>so could support your approach here too.

We have this kind of implementation tested in CHV and BXT.
Can I consider at least the BXT part as a sample for HSW+ platforms ?

Thanks,
Durga

>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Daniel Vetter]

On Fri, Sep 25, 2015 at 12:22:42PM +0000, R, Durgadoss wrote:
> Hi Daniel,
> 
> Thanks for having a look at it..
> 
> >-----Original Message-----
> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >Sent: Wednesday, September 23, 2015 3:14 PM
> >To: R, Durgadoss
> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >
> >On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
> >> Hi Jani,
> >>
> >> >-----Original Message-----
> >> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> >> >Sent: Wednesday, September 16, 2015 3:18 PM
> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
> >> >Cc: R, Durgadoss
> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >
> >> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
> >> >> This is an RFC series to start the review/discussion on approach
> >> >> to support USB type C based DP panel.
> >> >>
> >> >> To support USB type C alternate DP mode, the display driver needs to
> >> >> know the number of lanes required by the 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.
> >> >>
> >> >> The goal is to find out the number of lanes which can be supported
> >> >> using a particular cable so that we can cap 'max_available_lanes'
> >> >> to that number during modeset.
> >> >>
> >> >> These two patches are based on 4.2-rc2 and tested only on
> >> >> a BXT A1 platform for now.
> >> >>
> >> >> Brief summary of the approach taken:
> >> >> -----------------------------------
> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
> >> >>   with highest number of lanes/bandwidth possible. If it fails,
> >> >>   driver retries link training with lane/2 for same bandwidth.
> >> >>   We continue this procedure until we find a working configuration
> >> >>   of lane/bandwidth values. This 'number of lanes' is then
> >> >>   set as the 'max_available_lanes', so that the following
> >> >>   intel_dp_compute_config() during modeset picks it up as
> >> >>   max_lane_count (instead of 4 always, from DPCD).
> >> >
> >> >Would all of this work automatically if our link training sequence
> >> >followed the DP spec to the letter wrt degrading the link on failures?
> >>
> >> That is one part of it.
> >>
> >> Our intention is also to filter out the modes that cannot be set
> >> with 'max_available_lanes' through connector->mode_valid
> >> callback, which uses these variables. Otherwise, we risk failing
> >> a modeset that uses higher resolutions than possible.
> >>
> >> Sorry, I should have also added this as part of the commit message.
> >
> >One approach to implement DP link training to the spec is that if things
> >fail we enable the pipe anyway (since anything else would seriously
> >surprise userspace, especially for async modesets, and lead to hangs in
> >userspace if vblank interrupts don't happen). And then we generate a
> >hotplug event to inform userspace that something change with the monitor
> >configuration, to give userspace a chance to look at the filtered mode
> >list and select a new config it likes.
> >
> >That approach would fit rather well into the overall framework of how
> >detection/mode-config changes are done currently by keeping all the policy
> >for selecting the precise mode config in userspace. Downside is that for
> >usb type-C it would cause flicker since if we only have 2 lanes we'll
> >always first try the high-res mode and fail. So I think in the end we need
> 
> Yes, agreed.
> 
> >both approaches. Wrt the rfc it would be great if we can make it at least
> >somewhat platform-agnostic - anything on big core since hsw+ supports
> 
> By platform-agnostic,
> 
> do you mean to try and implement _upfront_link_train() 
> for few more platforms since HSW+ to see how we can re-use common code
> if any ?
> 
> If it is something else, please elaborate a bit more..
> 
> >enabling the DP port without enabling a pipe (because dp mst needs that),
> >so could support your approach here too.
> 
> We have this kind of implementation tested in CHV and BXT.
> Can I consider at least the BXT part as a sample for HSW+ platforms ?

Yeah, bxt works like hsw+ for ddi ports. So the idea is that extract the
link training for all of those with a high-level intel_* function used by
the upfront link training code. I did not know that we can enable the port
without a pipe on CHV though, do you have the code for that already?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

Hi Daniel,

>-----Original Message-----
>From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Monday, September 28, 2015 1:50 PM
>To: R, Durgadoss
>Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Fri, Sep 25, 2015 at 12:22:42PM +0000, R, Durgadoss wrote:
>> Hi Daniel,
>>
>> Thanks for having a look at it..
>>
>> >-----Original Message-----
>> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>> >Sent: Wednesday, September 23, 2015 3:14 PM
>> >To: R, Durgadoss
>> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >
>> >On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
>> >> Hi Jani,
>> >>
>> >> >-----Original Message-----
>> >> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
>> >> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >> >Cc: R, Durgadoss
>> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >> >
>> >> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
>> >> >> This is an RFC series to start the review/discussion on approach
>> >> >> to support USB type C based DP panel.
>> >> >>
>> >> >> To support USB type C alternate DP mode, the display driver needs to
>> >> >> know the number of lanes required by the 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.
>> >> >>
>> >> >> The goal is to find out the number of lanes which can be supported
>> >> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> >> to that number during modeset.
>> >> >>
>> >> >> These two patches are based on 4.2-rc2 and tested only on
>> >> >> a BXT A1 platform for now.
>> >> >>
>> >> >> Brief summary of the approach taken:
>> >> >> -----------------------------------
>> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >> >>   driver retries link training with lane/2 for same bandwidth.
>> >> >>   We continue this procedure until we find a working configuration
>> >> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >> >>   set as the 'max_available_lanes', so that the following
>> >> >>   intel_dp_compute_config() during modeset picks it up as
>> >> >>   max_lane_count (instead of 4 always, from DPCD).
>> >> >
>> >> >Would all of this work automatically if our link training sequence
>> >> >followed the DP spec to the letter wrt degrading the link on failures?
>> >>
>> >> That is one part of it.
>> >>
>> >> Our intention is also to filter out the modes that cannot be set
>> >> with 'max_available_lanes' through connector->mode_valid
>> >> callback, which uses these variables. Otherwise, we risk failing
>> >> a modeset that uses higher resolutions than possible.
>> >>
>> >> Sorry, I should have also added this as part of the commit message.
>> >
>> >One approach to implement DP link training to the spec is that if things
>> >fail we enable the pipe anyway (since anything else would seriously
>> >surprise userspace, especially for async modesets, and lead to hangs in
>> >userspace if vblank interrupts don't happen). And then we generate a
>> >hotplug event to inform userspace that something change with the monitor
>> >configuration, to give userspace a chance to look at the filtered mode
>> >list and select a new config it likes.
>> >
>> >That approach would fit rather well into the overall framework of how
>> >detection/mode-config changes are done currently by keeping all the policy
>> >for selecting the precise mode config in userspace. Downside is that for
>> >usb type-C it would cause flicker since if we only have 2 lanes we'll
>> >always first try the high-res mode and fail. So I think in the end we need
>>
>> Yes, agreed.
>>
>> >both approaches. Wrt the rfc it would be great if we can make it at least
>> >somewhat platform-agnostic - anything on big core since hsw+ supports
>>
>> By platform-agnostic,
>>
>> do you mean to try and implement _upfront_link_train()
>> for few more platforms since HSW+ to see how we can re-use common code
>> if any ?
>>
>> If it is something else, please elaborate a bit more..
>>
>> >enabling the DP port without enabling a pipe (because dp mst needs that),
>> >so could support your approach here too.
>>
>> We have this kind of implementation tested in CHV and BXT.
>> Can I consider at least the BXT part as a sample for HSW+ platforms ?
>
>Yeah, bxt works like hsw+ for ddi ports. So the idea is that extract the
>link training for all of those with a high-level intel_* function used by
>the upfront link training code. I did not know that we can enable the port
>without a pipe on CHV though, do you have the code for that already?

Yes, we have a similar implementation working on CHV also.
I chose to post BXT code since it is on a recent kernel (4.2-rc2) whereas
our CHV implementation was on 3.14..

Thanks,
Durga

>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Daniel Vetter]

On Mon, Sep 28, 2015 at 04:48:32PM +0000, R, Durgadoss wrote:
> Hi Daniel,
> 
> >-----Original Message-----
> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >Sent: Monday, September 28, 2015 1:50 PM
> >To: R, Durgadoss
> >Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >
> >On Fri, Sep 25, 2015 at 12:22:42PM +0000, R, Durgadoss wrote:
> >> Hi Daniel,
> >>
> >> Thanks for having a look at it..
> >>
> >> >-----Original Message-----
> >> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >> >Sent: Wednesday, September 23, 2015 3:14 PM
> >> >To: R, Durgadoss
> >> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
> >> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >
> >> >On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
> >> >> Hi Jani,
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> >> >> >Sent: Wednesday, September 16, 2015 3:18 PM
> >> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
> >> >> >Cc: R, Durgadoss
> >> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >> >
> >> >> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
> >> >> >> This is an RFC series to start the review/discussion on approach
> >> >> >> to support USB type C based DP panel.
> >> >> >>
> >> >> >> To support USB type C alternate DP mode, the display driver needs to
> >> >> >> know the number of lanes required by the 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.
> >> >> >>
> >> >> >> The goal is to find out the number of lanes which can be supported
> >> >> >> using a particular cable so that we can cap 'max_available_lanes'
> >> >> >> to that number during modeset.
> >> >> >>
> >> >> >> These two patches are based on 4.2-rc2 and tested only on
> >> >> >> a BXT A1 platform for now.
> >> >> >>
> >> >> >> Brief summary of the approach taken:
> >> >> >> -----------------------------------
> >> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
> >> >> >>   with highest number of lanes/bandwidth possible. If it fails,
> >> >> >>   driver retries link training with lane/2 for same bandwidth.
> >> >> >>   We continue this procedure until we find a working configuration
> >> >> >>   of lane/bandwidth values. This 'number of lanes' is then
> >> >> >>   set as the 'max_available_lanes', so that the following
> >> >> >>   intel_dp_compute_config() during modeset picks it up as
> >> >> >>   max_lane_count (instead of 4 always, from DPCD).
> >> >> >
> >> >> >Would all of this work automatically if our link training sequence
> >> >> >followed the DP spec to the letter wrt degrading the link on failures?
> >> >>
> >> >> That is one part of it.
> >> >>
> >> >> Our intention is also to filter out the modes that cannot be set
> >> >> with 'max_available_lanes' through connector->mode_valid
> >> >> callback, which uses these variables. Otherwise, we risk failing
> >> >> a modeset that uses higher resolutions than possible.
> >> >>
> >> >> Sorry, I should have also added this as part of the commit message.
> >> >
> >> >One approach to implement DP link training to the spec is that if things
> >> >fail we enable the pipe anyway (since anything else would seriously
> >> >surprise userspace, especially for async modesets, and lead to hangs in
> >> >userspace if vblank interrupts don't happen). And then we generate a
> >> >hotplug event to inform userspace that something change with the monitor
> >> >configuration, to give userspace a chance to look at the filtered mode
> >> >list and select a new config it likes.
> >> >
> >> >That approach would fit rather well into the overall framework of how
> >> >detection/mode-config changes are done currently by keeping all the policy
> >> >for selecting the precise mode config in userspace. Downside is that for
> >> >usb type-C it would cause flicker since if we only have 2 lanes we'll
> >> >always first try the high-res mode and fail. So I think in the end we need
> >>
> >> Yes, agreed.
> >>
> >> >both approaches. Wrt the rfc it would be great if we can make it at least
> >> >somewhat platform-agnostic - anything on big core since hsw+ supports
> >>
> >> By platform-agnostic,
> >>
> >> do you mean to try and implement _upfront_link_train()
> >> for few more platforms since HSW+ to see how we can re-use common code
> >> if any ?
> >>
> >> If it is something else, please elaborate a bit more..
> >>
> >> >enabling the DP port without enabling a pipe (because dp mst needs that),
> >> >so could support your approach here too.
> >>
> >> We have this kind of implementation tested in CHV and BXT.
> >> Can I consider at least the BXT part as a sample for HSW+ platforms ?
> >
> >Yeah, bxt works like hsw+ for ddi ports. So the idea is that extract the
> >link training for all of those with a high-level intel_* function used by
> >the upfront link training code. I did not know that we can enable the port
> >without a pipe on CHV though, do you have the code for that already?
> 
> Yes, we have a similar implementation working on CHV also.
> I chose to post BXT code since it is on a recent kernel (4.2-rc2) whereas
> our CHV implementation was on 3.14..

Would be interesting to post them all. Just to understand what the overall
requirements are.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[R, Durgadoss]

>-----Original Message-----
>From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>Sent: Tuesday, September 29, 2015 2:35 PM
>To: R, Durgadoss
>Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>
>On Mon, Sep 28, 2015 at 04:48:32PM +0000, R, Durgadoss wrote:
>> Hi Daniel,
>>
>> >-----Original Message-----
>> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>> >Sent: Monday, September 28, 2015 1:50 PM
>> >To: R, Durgadoss
>> >Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >
>> >On Fri, Sep 25, 2015 at 12:22:42PM +0000, R, Durgadoss wrote:
>> >> Hi Daniel,
>> >>
>> >> Thanks for having a look at it..
>> >>
>> >> >-----Original Message-----
>> >> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
>> >> >Sent: Wednesday, September 23, 2015 3:14 PM
>> >> >To: R, Durgadoss
>> >> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
>> >> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >> >
>> >> >On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
>> >> >> Hi Jani,
>> >> >>
>> >> >> >-----Original Message-----
>> >> >> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
>> >> >> >Sent: Wednesday, September 16, 2015 3:18 PM
>> >> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
>> >> >> >Cc: R, Durgadoss
>> >> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
>> >> >> >
>> >> >> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
>> >> >> >> This is an RFC series to start the review/discussion on approach
>> >> >> >> to support USB type C based DP panel.
>> >> >> >>
>> >> >> >> To support USB type C alternate DP mode, the display driver needs to
>> >> >> >> know the number of lanes required by the 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.
>> >> >> >>
>> >> >> >> The goal is to find out the number of lanes which can be supported
>> >> >> >> using a particular cable so that we can cap 'max_available_lanes'
>> >> >> >> to that number during modeset.
>> >> >> >>
>> >> >> >> These two patches are based on 4.2-rc2 and tested only on
>> >> >> >> a BXT A1 platform for now.
>> >> >> >>
>> >> >> >> Brief summary of the approach taken:
>> >> >> >> -----------------------------------
>> >> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
>> >> >> >>   with highest number of lanes/bandwidth possible. If it fails,
>> >> >> >>   driver retries link training with lane/2 for same bandwidth.
>> >> >> >>   We continue this procedure until we find a working configuration
>> >> >> >>   of lane/bandwidth values. This 'number of lanes' is then
>> >> >> >>   set as the 'max_available_lanes', so that the following
>> >> >> >>   intel_dp_compute_config() during modeset picks it up as
>> >> >> >>   max_lane_count (instead of 4 always, from DPCD).
>> >> >> >
>> >> >> >Would all of this work automatically if our link training sequence
>> >> >> >followed the DP spec to the letter wrt degrading the link on failures?
>> >> >>
>> >> >> That is one part of it.
>> >> >>
>> >> >> Our intention is also to filter out the modes that cannot be set
>> >> >> with 'max_available_lanes' through connector->mode_valid
>> >> >> callback, which uses these variables. Otherwise, we risk failing
>> >> >> a modeset that uses higher resolutions than possible.
>> >> >>
>> >> >> Sorry, I should have also added this as part of the commit message.
>> >> >
>> >> >One approach to implement DP link training to the spec is that if things
>> >> >fail we enable the pipe anyway (since anything else would seriously
>> >> >surprise userspace, especially for async modesets, and lead to hangs in
>> >> >userspace if vblank interrupts don't happen). And then we generate a
>> >> >hotplug event to inform userspace that something change with the monitor
>> >> >configuration, to give userspace a chance to look at the filtered mode
>> >> >list and select a new config it likes.
>> >> >
>> >> >That approach would fit rather well into the overall framework of how
>> >> >detection/mode-config changes are done currently by keeping all the policy
>> >> >for selecting the precise mode config in userspace. Downside is that for
>> >> >usb type-C it would cause flicker since if we only have 2 lanes we'll
>> >> >always first try the high-res mode and fail. So I think in the end we need
>> >>
>> >> Yes, agreed.
>> >>
>> >> >both approaches. Wrt the rfc it would be great if we can make it at least
>> >> >somewhat platform-agnostic - anything on big core since hsw+ supports
>> >>
>> >> By platform-agnostic,
>> >>
>> >> do you mean to try and implement _upfront_link_train()
>> >> for few more platforms since HSW+ to see how we can re-use common code
>> >> if any ?
>> >>
>> >> If it is something else, please elaborate a bit more..
>> >>
>> >> >enabling the DP port without enabling a pipe (because dp mst needs that),
>> >> >so could support your approach here too.
>> >>
>> >> We have this kind of implementation tested in CHV and BXT.
>> >> Can I consider at least the BXT part as a sample for HSW+ platforms ?
>> >
>> >Yeah, bxt works like hsw+ for ddi ports. So the idea is that extract the
>> >link training for all of those with a high-level intel_* function used by
>> >the upfront link training code. I did not know that we can enable the port
>> >without a pipe on CHV though, do you have the code for that already?
>>
>> Yes, we have a similar implementation working on CHV also.
>> I chose to post BXT code since it is on a recent kernel (4.2-rc2) whereas
>> our CHV implementation was on 3.14..
>
>Would be interesting to post them all. Just to understand what the overall
>requirements are.

Sure. I will try out a platform agnostic implementation for hsw+ and post
it as RFC. With that, will add the CHV patch also.

Thanks,
Durga

>-Daniel
>--
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT

[Daniel Vetter]

On Wed, Sep 30, 2015 at 05:32:41PM +0000, R, Durgadoss wrote:
> >-----Original Message-----
> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >Sent: Tuesday, September 29, 2015 2:35 PM
> >To: R, Durgadoss
> >Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >
> >On Mon, Sep 28, 2015 at 04:48:32PM +0000, R, Durgadoss wrote:
> >> Hi Daniel,
> >>
> >> >-----Original Message-----
> >> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >> >Sent: Monday, September 28, 2015 1:50 PM
> >> >To: R, Durgadoss
> >> >Cc: Daniel Vetter; Jani Nikula; intel-gfx@lists.freedesktop.org
> >> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >
> >> >On Fri, Sep 25, 2015 at 12:22:42PM +0000, R, Durgadoss wrote:
> >> >> Hi Daniel,
> >> >>
> >> >> Thanks for having a look at it..
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Daniel Vetter [mailto:daniel.vetter@ffwll.ch] On Behalf Of Daniel Vetter
> >> >> >Sent: Wednesday, September 23, 2015 3:14 PM
> >> >> >To: R, Durgadoss
> >> >> >Cc: Jani Nikula; intel-gfx@lists.freedesktop.org
> >> >> >Subject: Re: [Intel-gfx] [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >> >
> >> >> >On Wed, Sep 16, 2015 at 10:57:45AM +0000, R, Durgadoss wrote:
> >> >> >> Hi Jani,
> >> >> >>
> >> >> >> >-----Original Message-----
> >> >> >> >From: Jani Nikula [mailto:jani.nikula@linux.intel.com]
> >> >> >> >Sent: Wednesday, September 16, 2015 3:18 PM
> >> >> >> >To: R, Durgadoss; intel-gfx@lists.freedesktop.org
> >> >> >> >Cc: R, Durgadoss
> >> >> >> >Subject: Re: [RFC DP-typeC 0/2] Support USB typeC based DP on BXT
> >> >> >> >
> >> >> >> >On Tue, 15 Sep 2015, Durgadoss R <durgadoss.r@intel.com> wrote:
> >> >> >> >> This is an RFC series to start the review/discussion on approach
> >> >> >> >> to support USB type C based DP panel.
> >> >> >> >>
> >> >> >> >> To support USB type C alternate DP mode, the display driver needs to
> >> >> >> >> know the number of lanes required by the 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.
> >> >> >> >>
> >> >> >> >> The goal is to find out the number of lanes which can be supported
> >> >> >> >> using a particular cable so that we can cap 'max_available_lanes'
> >> >> >> >> to that number during modeset.
> >> >> >> >>
> >> >> >> >> These two patches are based on 4.2-rc2 and tested only on
> >> >> >> >> a BXT A1 platform for now.
> >> >> >> >>
> >> >> >> >> Brief summary of the approach taken:
> >> >> >> >> -----------------------------------
> >> >> >> >> 1.As soon as DP-hotplug is detected, driver starts link training
> >> >> >> >>   with highest number of lanes/bandwidth possible. If it fails,
> >> >> >> >>   driver retries link training with lane/2 for same bandwidth.
> >> >> >> >>   We continue this procedure until we find a working configuration
> >> >> >> >>   of lane/bandwidth values. This 'number of lanes' is then
> >> >> >> >>   set as the 'max_available_lanes', so that the following
> >> >> >> >>   intel_dp_compute_config() during modeset picks it up as
> >> >> >> >>   max_lane_count (instead of 4 always, from DPCD).
> >> >> >> >
> >> >> >> >Would all of this work automatically if our link training sequence
> >> >> >> >followed the DP spec to the letter wrt degrading the link on failures?
> >> >> >>
> >> >> >> That is one part of it.
> >> >> >>
> >> >> >> Our intention is also to filter out the modes that cannot be set
> >> >> >> with 'max_available_lanes' through connector->mode_valid
> >> >> >> callback, which uses these variables. Otherwise, we risk failing
> >> >> >> a modeset that uses higher resolutions than possible.
> >> >> >>
> >> >> >> Sorry, I should have also added this as part of the commit message.
> >> >> >
> >> >> >One approach to implement DP link training to the spec is that if things
> >> >> >fail we enable the pipe anyway (since anything else would seriously
> >> >> >surprise userspace, especially for async modesets, and lead to hangs in
> >> >> >userspace if vblank interrupts don't happen). And then we generate a
> >> >> >hotplug event to inform userspace that something change with the monitor
> >> >> >configuration, to give userspace a chance to look at the filtered mode
> >> >> >list and select a new config it likes.
> >> >> >
> >> >> >That approach would fit rather well into the overall framework of how
> >> >> >detection/mode-config changes are done currently by keeping all the policy
> >> >> >for selecting the precise mode config in userspace. Downside is that for
> >> >> >usb type-C it would cause flicker since if we only have 2 lanes we'll
> >> >> >always first try the high-res mode and fail. So I think in the end we need
> >> >>
> >> >> Yes, agreed.
> >> >>
> >> >> >both approaches. Wrt the rfc it would be great if we can make it at least
> >> >> >somewhat platform-agnostic - anything on big core since hsw+ supports
> >> >>
> >> >> By platform-agnostic,
> >> >>
> >> >> do you mean to try and implement _upfront_link_train()
> >> >> for few more platforms since HSW+ to see how we can re-use common code
> >> >> if any ?
> >> >>
> >> >> If it is something else, please elaborate a bit more..
> >> >>
> >> >> >enabling the DP port without enabling a pipe (because dp mst needs that),
> >> >> >so could support your approach here too.
> >> >>
> >> >> We have this kind of implementation tested in CHV and BXT.
> >> >> Can I consider at least the BXT part as a sample for HSW+ platforms ?
> >> >
> >> >Yeah, bxt works like hsw+ for ddi ports. So the idea is that extract the
> >> >link training for all of those with a high-level intel_* function used by
> >> >the upfront link training code. I did not know that we can enable the port
> >> >without a pipe on CHV though, do you have the code for that already?
> >>
> >> Yes, we have a similar implementation working on CHV also.
> >> I chose to post BXT code since it is on a recent kernel (4.2-rc2) whereas
> >> our CHV implementation was on 3.14..
> >
> >Would be interesting to post them all. Just to understand what the overall
> >requirements are.
> 
> Sure. I will try out a platform agnostic implementation for hsw+ and post
> it as RFC. With that, will add the CHV patch also.

Excellent, sounds great.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx