All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
@ 2018-05-09  7:13 Jani Nikula
  2018-05-09  8:35 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 7+ messages in thread
From: Jani Nikula @ 2018-05-09  7:13 UTC (permalink / raw)
  To: intel-gfx; +Cc: jani.nikula, Rodrigo Vivi

We've opted to use the maximum link rate and lane count for eDP panels,
because typically the maximum supported configuration reported by the
panel has matched the native resolution requirements of the panel, and
optimizing the link has lead to problems.

With eDP 1.4 rate select method and DSC features, this is decreasingly
the case. There's a need to optimize the link parameters. Moreover,
already eDP 1.3 states fast link with fewer lanes is preferred over the
wide and slow. (Wide and slow should still be more reliable for longer
cable lengths.)

Additionally, there have been reports of panels failing on arbitrary
link configurations, although arguably all configurations they claim to
support should work.

Optimize eDP 1.4+ link config fast and narrow.

Side note: The implementation has a near duplicate of the link config
function, with just the two inner for loops turned inside out. Perhaps
there'd be a way to make this, say, more table driven to reduce the
duplication, but seems like that would lead to duplication in the table
generation. We'll also have to see how the link config optimization for
DSC turns out.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

Untested. It's possible this helps the referenced bug. The downside is
that this patch has a bunch of dependencies that are too much to
backport to stable kernels. If the patch works, we may need to consider
hacking together an uglier backport.
---
 drivers/gpu/drm/i915/intel_dp.c | 73 ++++++++++++++++++++++++++++++++++-------
 1 file changed, 62 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..1ec62965ece3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
 	return false;
 }
 
+/* Optimize link config in order: max bpp, min lanes, min clock */
+static bool
+intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
+				  struct intel_crtc_state *pipe_config,
+				  const struct link_config_limits *limits)
+{
+	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
+	int bpp, clock, lane_count;
+	int mode_rate, link_clock, link_avail;
+
+	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
+		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
+						   bpp);
+
+		for (lane_count = limits->min_lane_count;
+		     lane_count <= limits->max_lane_count;
+		     lane_count <<= 1) {
+			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
+				link_clock = intel_dp->common_rates[clock];
+				link_avail = intel_dp_max_data_rate(link_clock,
+								    lane_count);
+
+				if (mode_rate <= link_avail) {
+					pipe_config->lane_count = lane_count;
+					pipe_config->pipe_bpp = bpp;
+					pipe_config->port_clock = link_clock;
+
+					return true;
+				}
+			}
+		}
+	}
+
+	return false;
+}
+
 static bool
 intel_dp_compute_link_config(struct intel_encoder *encoder,
 			     struct intel_crtc_state *pipe_config)
@@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 	limits.min_bpp = 6 * 3;
 	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
 
-	if (intel_dp_is_edp(intel_dp)) {
+	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
 		/*
 		 * Use the maximum clock and number of lanes the eDP panel
-		 * advertizes being capable of. The panels are generally
-		 * designed to support only a single clock and lane
-		 * configuration, and typically these values correspond to the
-		 * native resolution of the panel.
+		 * advertizes being capable of. The eDP 1.3 and earlier panels
+		 * are generally designed to support only a single clock and
+		 * lane configuration, and typically these values correspond to
+		 * the native resolution of the panel. With eDP 1.4 rate select
+		 * and DSC, this is decreasingly the case, and we need to be
+		 * able to select less than maximum link config.
 		 */
 		limits.min_lane_count = limits.max_lane_count;
 		limits.min_clock = limits.max_clock;
@@ -1812,12 +1850,25 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
 		      intel_dp->common_rates[limits.max_clock],
 		      limits.max_bpp, adjusted_mode->crtc_clock);
 
-	/*
-	 * Optimize for slow and wide. This is the place to add alternative
-	 * optimization policy.
-	 */
-	if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits))
-		return false;
+	if (intel_dp_is_edp(intel_dp)) {
+		/*
+		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
+		 * section A.1: "It is recommended that the minimum number of
+		 * lanes be used, using the minimum link rate allowed for that
+		 * lane configuration."
+		 *
+		 * Note that we use the max clock and lane count for eDP 1.3 and
+		 * earlier, and fast vs. wide is irrelevant.
+		 */
+		if (!intel_dp_compute_link_config_fast(intel_dp, pipe_config,
+						       &limits))
+			return false;
+	} else {
+		/* Optimize for slow and wide. */
+		if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config,
+						       &limits))
+			return false;
+	}
 
 	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
 		      pipe_config->lane_count, pipe_config->port_clock,
-- 
2.11.0

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

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09  7:13 [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow Jani Nikula
@ 2018-05-09  8:35 ` Patchwork
  2018-05-09 10:08 ` ✓ Fi.CI.IGT: " Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-05-09  8:35 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
URL   : https://patchwork.freedesktop.org/series/42923/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4161 -> Patchwork_8957 =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8957 need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8957, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/42923/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8957:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_gttfill@basic:
      fi-pnv-d510:        PASS -> SKIP

    
== Known issues ==

  Here are the changes found in Patchwork_8957 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@debugfs_test@read_all_entries:
      fi-snb-2520m:       PASS -> INCOMPLETE (fdo#103713)

    igt@gem_mmap_gtt@basic-small-bo-tiledx:
      fi-gdg-551:         PASS -> FAIL (fdo#102575)

    igt@kms_frontbuffer_tracking@basic:
      fi-cnl-y3:          PASS -> FAIL (fdo#104724, fdo#103167)

    igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
      fi-skl-guc:         PASS -> FAIL (fdo#103191, fdo#104724)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
      fi-cnl-y3:          PASS -> DMESG-WARN (fdo#104951)

    igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
      fi-bxt-dsi:         PASS -> INCOMPLETE (fdo#103927)

    
  fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724
  fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951


== Participating hosts (40 -> 37) ==

  Additional (1): fi-glk-j4005 
  Missing    (4): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-skl-6700hq 


== Build changes ==

    * Linux: CI_DRM_4161 -> Patchwork_8957

  CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8957: 14195da35f10255240ce36a4f0c2628ba2340110 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit


== Linux commits ==

14195da35f10 drm/i915/dp: optimize eDP 1.4+ link config fast and narrow

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8957/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* ✓ Fi.CI.IGT: success for drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09  7:13 [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow Jani Nikula
  2018-05-09  8:35 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2018-05-09 10:08 ` Patchwork
  2018-05-09 12:21 ` [RFC] " Rodrigo Vivi
  2018-05-09 18:58 ` Manasi Navare
  3 siblings, 0 replies; 7+ messages in thread
From: Patchwork @ 2018-05-09 10:08 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx

== Series Details ==

Series: drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
URL   : https://patchwork.freedesktop.org/series/42923/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4161_full -> Patchwork_8957_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_8957_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_8957_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/42923/revisions/1/mbox/

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_8957_full:

  === IGT changes ===

    ==== Warnings ====

    igt@gem_exec_schedule@deep-blt:
      shard-kbl:          SKIP -> PASS +1

    
== Known issues ==

  Here are the changes found in Patchwork_8957_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_flip@2x-flip-vs-absolute-wf_vblank:
      shard-hsw:          PASS -> FAIL (fdo#100368)

    igt@kms_flip@flip-vs-expired-vblank-interruptible:
      shard-glk:          PASS -> FAIL (fdo#102887)

    igt@kms_flip@plain-flip-fb-recreate-interruptible:
      shard-glk:          PASS -> FAIL (fdo#100368) +2

    
    ==== Possible fixes ====

    igt@kms_flip@dpms-vs-vblank-race-interruptible:
      shard-glk:          FAIL (fdo#103060) -> PASS

    igt@kms_flip@flip-vs-wf_vblank-interruptible:
      shard-glk:          FAIL (fdo#100368) -> PASS +1

    igt@kms_flip@modeset-vs-vblank-race:
      shard-hsw:          FAIL (fdo#103060) -> PASS

    igt@kms_vblank@pipe-b-accuracy-idle:
      shard-hsw:          FAIL (fdo#102583) -> PASS

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583
  fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887
  fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060


== Participating hosts (9 -> 9) ==

  No changes in participating hosts


== Build changes ==

    * Linux: CI_DRM_4161 -> Patchwork_8957

  CI_DRM_4161: f20dbaa0dfba8b33c677c084d39fc730309c5af2 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4468: 548a894dc904c4628522dbbc77cb179a4c965ebc @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_8957: 14195da35f10255240ce36a4f0c2628ba2340110 @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4468: 1e60f1499e5b71b6d5a747189d7c28f57359a87f @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8957/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09  7:13 [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow Jani Nikula
  2018-05-09  8:35 ` ✓ Fi.CI.BAT: success for " Patchwork
  2018-05-09 10:08 ` ✓ Fi.CI.IGT: " Patchwork
@ 2018-05-09 12:21 ` Rodrigo Vivi
  2018-05-09 15:09   ` Atwood, Matthew S
  2018-05-09 18:58 ` Manasi Navare
  3 siblings, 1 reply; 7+ messages in thread
From: Rodrigo Vivi @ 2018-05-09 12:21 UTC (permalink / raw)
  To: Jani Nikula, Atwood, Matthew S; +Cc: intel-gfx

On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> We've opted to use the maximum link rate and lane count for eDP panels,
> because typically the maximum supported configuration reported by the
> panel has matched the native resolution requirements of the panel, and
> optimizing the link has lead to problems.
> 
> With eDP 1.4 rate select method and DSC features, this is decreasingly
> the case. There's a need to optimize the link parameters. Moreover,
> already eDP 1.3 states fast link with fewer lanes is preferred over the
> wide and slow. (Wide and slow should still be more reliable for longer
> cable lengths.)
> 
> Additionally, there have been reports of panels failing on arbitrary
> link configurations, although arguably all configurations they claim to
> support should work.
> 
> Optimize eDP 1.4+ link config fast and narrow.
> 
> Side note: The implementation has a near duplicate of the link config
> function, with just the two inner for loops turned inside out. Perhaps
> there'd be a way to make this, say, more table driven to reduce the
> duplication, but seems like that would lead to duplication in the table
> generation. We'll also have to see how the link config optimization for
> DSC turns out.
> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>

Cc: Matt Atwood <matthew.s.atwood@intel.com>

I believe Matt is interested on this and know who could test this for us.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

This matches my understand of the eDP 1.4 spec I believe this is the
way to go, so

Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

but probably better to get a proper review and wait for someone
to test...

> 
> ---
> 
> Untested. It's possible this helps the referenced bug. The downside is
> that this patch has a bunch of dependencies that are too much to
> backport to stable kernels. If the patch works, we may need to consider
> hacking together an uglier backport.
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 73 ++++++++++++++++++++++++++++++++++-------
>  1 file changed, 62 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..1ec62965ece3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
>  	return false;
>  }
>  
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static bool
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> +				  struct intel_crtc_state *pipe_config,
> +				  const struct link_config_limits *limits)
> +{
> +	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
> +	int bpp, clock, lane_count;
> +	int mode_rate, link_clock, link_avail;
> +
> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +						   bpp);
> +
> +		for (lane_count = limits->min_lane_count;
> +		     lane_count <= limits->max_lane_count;
> +		     lane_count <<= 1) {
> +			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> +				link_clock = intel_dp->common_rates[clock];
> +				link_avail = intel_dp_max_data_rate(link_clock,
> +								    lane_count);
> +
> +				if (mode_rate <= link_avail) {
> +					pipe_config->lane_count = lane_count;
> +					pipe_config->pipe_bpp = bpp;
> +					pipe_config->port_clock = link_clock;
> +
> +					return true;
> +				}
> +			}
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static bool
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>  			     struct intel_crtc_state *pipe_config)
> @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  	limits.min_bpp = 6 * 3;
>  	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>  
> -	if (intel_dp_is_edp(intel_dp)) {
> +	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
>  		/*
>  		 * Use the maximum clock and number of lanes the eDP panel
> -		 * advertizes being capable of. The panels are generally
> -		 * designed to support only a single clock and lane
> -		 * configuration, and typically these values correspond to the
> -		 * native resolution of the panel.
> +		 * advertizes being capable of. The eDP 1.3 and earlier panels
> +		 * are generally designed to support only a single clock and
> +		 * lane configuration, and typically these values correspond to
> +		 * the native resolution of the panel. With eDP 1.4 rate select
> +		 * and DSC, this is decreasingly the case, and we need to be
> +		 * able to select less than maximum link config.
>  		 */
>  		limits.min_lane_count = limits.max_lane_count;
>  		limits.min_clock = limits.max_clock;
> @@ -1812,12 +1850,25 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  		      intel_dp->common_rates[limits.max_clock],
>  		      limits.max_bpp, adjusted_mode->crtc_clock);
>  
> -	/*
> -	 * Optimize for slow and wide. This is the place to add alternative
> -	 * optimization policy.
> -	 */
> -	if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits))
> -		return false;
> +	if (intel_dp_is_edp(intel_dp)) {
> +		/*
> +		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> +		 * section A.1: "It is recommended that the minimum number of
> +		 * lanes be used, using the minimum link rate allowed for that
> +		 * lane configuration."
> +		 *
> +		 * Note that we use the max clock and lane count for eDP 1.3 and
> +		 * earlier, and fast vs. wide is irrelevant.
> +		 */
> +		if (!intel_dp_compute_link_config_fast(intel_dp, pipe_config,
> +						       &limits))
> +			return false;
> +	} else {
> +		/* Optimize for slow and wide. */
> +		if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config,
> +						       &limits))
> +			return false;
> +	}
>  
>  	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
>  		      pipe_config->lane_count, pipe_config->port_clock,
> -- 
> 2.11.0
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09 12:21 ` [RFC] " Rodrigo Vivi
@ 2018-05-09 15:09   ` Atwood, Matthew S
  2018-05-09 15:30     ` Atwood, Matthew S
  0 siblings, 1 reply; 7+ messages in thread
From: Atwood, Matthew S @ 2018-05-09 15:09 UTC (permalink / raw)
  To: Vivi, Rodrigo, Nikula, Jani; +Cc: intel-gfx

On Wed, 2018-05-09 at 05:21 -0700, Rodrigo Vivi wrote:
> On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> > We've opted to use the maximum link rate and lane count for eDP
> > panels,
> > because typically the maximum supported configuration reported by
> > the
> > panel has matched the native resolution requirements of the panel,
> > and
> > optimizing the link has lead to problems.
> > 
> > With eDP 1.4 rate select method and DSC features, this is
> > decreasingly
> > the case. There's a need to optimize the link parameters. Moreover,
> > already eDP 1.3 states fast link with fewer lanes is preferred over
> > the
> > wide and slow. (Wide and slow should still be more reliable for
> > longer
> > cable lengths.)
> > 
> > Additionally, there have been reports of panels failing on
> > arbitrary
> > link configurations, although arguably all configurations they
> > claim to
> > support should work.
> > 
> > Optimize eDP 1.4+ link config fast and narrow.
> > 
> > Side note: The implementation has a near duplicate of the link
> > config
> > function, with just the two inner for loops turned inside out.
> > Perhaps
> > there'd be a way to make this, say, more table driven to reduce the
> > duplication, but seems like that would lead to duplication in the
> > table
> > generation. We'll also have to see how the link config optimization
> > for
> > DSC turns out.
> > 
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> Cc: Matt Atwood <matthew.s.atwood@intel.com>
> 
> I believe Matt is interested on this and know who could test this for
> us.
I'm actually in the process of working with my counterpart at Google to
actually quantify what power is saved. With both chromeos-
4.14/chromeos-4.4 patches to do so across multiple boards and multiple
systems.
> 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> This matches my understand of the eDP 1.4 spec I believe this is the
> way to go, so
> 
> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> but probably better to get a proper review and wait for someone
> to test...
> 
> > 
> > ---
> > 
> > Untested. It's possible this helps the referenced bug. The downside
> > is
> > that this patch has a bunch of dependencies that are too much to
> > backport to stable kernels. If the patch works, we may need to
> > consider
> > hacking together an uglier backport.
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 73
> > ++++++++++++++++++++++++++++++++++-------
> >  1 file changed, 62 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index dde92e4af5d3..1ec62965ece3 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct
> > intel_dp *intel_dp,
> >  	return false;
> >  }
> >  
> > +/* Optimize link config in order: max bpp, min lanes, min clock */
> > +static bool
> > +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> > +				  struct intel_crtc_state
> > *pipe_config,
> > +				  const struct link_config_limits
> > *limits)
I personally called this intel_dp_compute_link_config_narrow as a
counterpart to the "wide" implementation.
> > +{
> > +	struct drm_display_mode *adjusted_mode = &pipe_config-
> > >base.adjusted_mode;
> > +	int bpp, clock, lane_count;
> > +	int mode_rate, link_clock, link_avail;
> > +
> > +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -=
> > 2 * 3) {
> > +		mode_rate = intel_dp_link_required(adjusted_mode-
> > >crtc_clock,
> > +						   bpp);
> > +
> > +		for (lane_count = limits->min_lane_count;
> > +		     lane_count <= limits->max_lane_count;
> > +		     lane_count <<= 1) {
> > +			for (clock = limits->min_clock; clock <=
> > limits->max_clock; clock++) {
> > +				link_clock = intel_dp-
> > >common_rates[clock];
> > +				link_avail =
> > intel_dp_max_data_rate(link_clock,
> > +								  
> >   lane_count);
> > +
> > +				if (mode_rate <= link_avail) {
> > +					pipe_config->lane_count =
> > lane_count;
> > +					pipe_config->pipe_bpp =
> > bpp;
> > +					pipe_config->port_clock =
> > link_clock;
> > +
> > +					return true;
> > +				}
> > +			}
> > +		}
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  static bool
> >  intel_dp_compute_link_config(struct intel_encoder *encoder,
> >  			     struct intel_crtc_state *pipe_config)
> > @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct
> > intel_encoder *encoder,
> >  	limits.min_bpp = 6 * 3;
> >  	limits.max_bpp = intel_dp_compute_bpp(intel_dp,
> > pipe_config);
> >  
> > -	if (intel_dp_is_edp(intel_dp)) {
> > +	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] <
> > DP_EDP_14) {
> >  		/*
> >  		 * Use the maximum clock and number of lanes the
> > eDP panel
> > -		 * advertizes being capable of. The panels are
> > generally
> > -		 * designed to support only a single clock and
> > lane
> > -		 * configuration, and typically these values
> > correspond to the
> > -		 * native resolution of the panel.
> > +		 * advertizes being capable of. The eDP 1.3 and
> > earlier panels
> > +		 * are generally designed to support only a single
> > clock and
> > +		 * lane configuration, and typically these values
> > correspond to
> > +		 * the native resolution of the panel. With eDP
> > 1.4 rate select
> > +		 * and DSC, this is decreasingly the case, and we
> > need to be
> > +		 * able to select less than maximum link config.
> >  		 */
> >  		limits.min_lane_count = limits.max_lane_count;
> >  		limits.min_clock = limits.max_clock;
> > @@ -1812,12 +1850,25 @@ intel_dp_compute_link_config(struct
> > intel_encoder *encoder,
> >  		      intel_dp->common_rates[limits.max_clock],
> >  		      limits.max_bpp, adjusted_mode->crtc_clock);
> >  
> > -	/*
> > -	 * Optimize for slow and wide. This is the place to add
> > alternative
> > -	 * optimization policy.
> > -	 */
> > -	if (!intel_dp_compute_link_config_wide(intel_dp,
> > pipe_config, &limits))
> > -		return false;
> > +	if (intel_dp_is_edp(intel_dp)) {
> > +		/*
> > +		 * Optimize for fast and narrow. eDP 1.3 section
> > 3.3 and eDP 1.4
> > +		 * section A.1: "It is recommended that the
> > minimum number of
> > +		 * lanes be used, using the minimum link rate
> > allowed for that
> > +		 * lane configuration."
> > +		 *
> > +		 * Note that we use the max clock and lane count
> > for eDP 1.3 and
> > +		 * earlier, and fast vs. wide is irrelevant.
> > +		 */
This is where I got hung up on *many* eDP panels. This will break many
pre edp 1.4 panels. I wrapped mine on a DPCD compare to DP_DPCD_REV.
> > +		if (!intel_dp_compute_link_config_fast(intel_dp,
> > pipe_config,
> > +						       &limits))
> > +			return false;
> > +	} else {
> > +		/* Optimize for slow and wide. */
> > +		if (!intel_dp_compute_link_config_wide(intel_dp,
> > pipe_config,
> > +						       &limits))
> > +			return false;
> > +	}
> >  
> >  	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
> >  		      pipe_config->lane_count, pipe_config-
> > >port_clock,
> > -- 
> > 2.11.0
> > 
I'm honestly glad that someone else cares I know in the case of the
wide optimization on a product I was working one we saved 200 uW, I'm
hoping for a bigger share with the narrow/fast implementation.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09 15:09   ` Atwood, Matthew S
@ 2018-05-09 15:30     ` Atwood, Matthew S
  0 siblings, 0 replies; 7+ messages in thread
From: Atwood, Matthew S @ 2018-05-09 15:30 UTC (permalink / raw)
  To: Vivi, Rodrigo, Nikula, Jani; +Cc: intel-gfx

On Wed, 2018-05-09 at 08:09 -0700, Matt Atwood wrote:
> On Wed, 2018-05-09 at 05:21 -0700, Rodrigo Vivi wrote:
> > On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> > > We've opted to use the maximum link rate and lane count for eDP
> > > panels,
> > > because typically the maximum supported configuration reported by
> > > the
> > > panel has matched the native resolution requirements of the
> > > panel,
> > > and
> > > optimizing the link has lead to problems.
> > > 
> > > With eDP 1.4 rate select method and DSC features, this is
> > > decreasingly
> > > the case. There's a need to optimize the link parameters.
> > > Moreover,
> > > already eDP 1.3 states fast link with fewer lanes is preferred
> > > over
> > > the
> > > wide and slow. (Wide and slow should still be more reliable for
> > > longer
> > > cable lengths.)
> > > 
> > > Additionally, there have been reports of panels failing on
> > > arbitrary
> > > link configurations, although arguably all configurations they
> > > claim to
> > > support should work.
> > > 
> > > Optimize eDP 1.4+ link config fast and narrow.
> > > 
> > > Side note: The implementation has a near duplicate of the link
> > > config
> > > function, with just the two inner for loops turned inside out.
> > > Perhaps
> > > there'd be a way to make this, say, more table driven to reduce
> > > the
> > > duplication, but seems like that would lead to duplication in the
> > > table
> > > generation. We'll also have to see how the link config
> > > optimization
> > > for
> > > DSC turns out.
> > > 
> > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Cc: Manasi Navare <manasi.d.navare@intel.com>
> > > Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > Cc: Matt Atwood <matthew.s.atwood@intel.com>
> > 
> > I believe Matt is interested on this and know who could test this
> > for
> > us.
> 
> I'm actually in the process of working with my counterpart at Google
> to
> actually quantify what power is saved. With both chromeos-
> 4.14/chromeos-4.4 patches to do so across multiple boards and
> multiple
> systems.
> > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > 
> > This matches my understand of the eDP 1.4 spec I believe this is
> > the
> > way to go, so
> > 
> > Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > 
> > but probably better to get a proper review and wait for someone
> > to test...
> > 
> > > 
> > > ---
> > > 
> > > Untested. It's possible this helps the referenced bug. The
> > > downside
> > > is
> > > that this patch has a bunch of dependencies that are too much to
> > > backport to stable kernels. If the patch works, we may need to
> > > consider
> > > hacking together an uglier backport.
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 73
> > > ++++++++++++++++++++++++++++++++++-------
> > >  1 file changed, 62 insertions(+), 11 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index dde92e4af5d3..1ec62965ece3 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct
> > > intel_dp *intel_dp,
> > >  	return false;
> > >  }
> > >  
> > > +/* Optimize link config in order: max bpp, min lanes, min clock
> > > */
> > > +static bool
> > > +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> > > +				  struct intel_crtc_state
> > > *pipe_config,
> > > +				  const struct
> > > link_config_limits
> > > *limits)
> 
> I personally called this intel_dp_compute_link_config_narrow as a
> counterpart to the "wide" implementation.
> > > +{
> > > +	struct drm_display_mode *adjusted_mode = &pipe_config-
> > > > base.adjusted_mode;
> > > 
> > > +	int bpp, clock, lane_count;
> > > +	int mode_rate, link_clock, link_avail;
> > > +
> > > +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp
> > > -=
> > > 2 * 3) {
> > > +		mode_rate =
> > > intel_dp_link_required(adjusted_mode-
> > > > crtc_clock,
> > > 
> > > +						   bpp);
> > > +
> > > +		for (lane_count = limits->min_lane_count;
> > > +		     lane_count <= limits->max_lane_count;
> > > +		     lane_count <<= 1) {
> > > +			for (clock = limits->min_clock; clock <=
> > > limits->max_clock; clock++) {
> > > +				link_clock = intel_dp-
> > > > common_rates[clock];
> > > 
> > > +				link_avail =
> > > intel_dp_max_data_rate(link_clock,
> > > +								
> > >   
> > >   lane_count);
> > > +
> > > +				if (mode_rate <= link_avail) {
> > > +					pipe_config->lane_count
> > > =
> > > lane_count;
> > > +					pipe_config->pipe_bpp =
> > > bpp;
> > > +					pipe_config->port_clock
> > > =
> > > link_clock;
> > > +
> > > +					return true;
> > > +				}
> > > +			}
> > > +		}
> > > +	}
> > > +
> > > +	return false;
> > > +}
> > > +
> > >  static bool
> > >  intel_dp_compute_link_config(struct intel_encoder *encoder,
> > >  			     struct intel_crtc_state
> > > *pipe_config)
> > > @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct
> > > intel_encoder *encoder,
> > >  	limits.min_bpp = 6 * 3;
> > >  	limits.max_bpp = intel_dp_compute_bpp(intel_dp,
> > > pipe_config);
> > >  
> > > -	if (intel_dp_is_edp(intel_dp)) {
> > > +	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] <
> > > DP_EDP_14) {
> > >  		/*
> > >  		 * Use the maximum clock and number of lanes the
> > > eDP panel
> > > -		 * advertizes being capable of. The panels are
> > > generally
> > > -		 * designed to support only a single clock and
> > > lane
> > > -		 * configuration, and typically these values
> > > correspond to the
> > > -		 * native resolution of the panel.
> > > +		 * advertizes being capable of. The eDP 1.3 and
> > > earlier panels
> > > +		 * are generally designed to support only a
> > > single
> > > clock and
> > > +		 * lane configuration, and typically these
> > > values
> > > correspond to
> > > +		 * the native resolution of the panel. With eDP
> > > 1.4 rate select
> > > +		 * and DSC, this is decreasingly the case, and
> > > we
> > > need to be
> > > +		 * able to select less than maximum link config.
> > >  		 */
> > >  		limits.min_lane_count = limits.max_lane_count;
> > >  		limits.min_clock = limits.max_clock;
> > > @@ -1812,12 +1850,25 @@ intel_dp_compute_link_config(struct
> > > intel_encoder *encoder,
> > >  		      intel_dp->common_rates[limits.max_clock],
> > >  		      limits.max_bpp, adjusted_mode-
> > > >crtc_clock);
> > >  
> > > -	/*
> > > -	 * Optimize for slow and wide. This is the place to add
> > > alternative
> > > -	 * optimization policy.
> > > -	 */
> > > -	if (!intel_dp_compute_link_config_wide(intel_dp,
> > > pipe_config, &limits))
> > > -		return false;
> > > +	if (intel_dp_is_edp(intel_dp)) {
> > > +		/*
> > > +		 * Optimize for fast and narrow. eDP 1.3 section
> > > 3.3 and eDP 1.4
> > > +		 * section A.1: "It is recommended that the
> > > minimum number of
> > > +		 * lanes be used, using the minimum link rate
> > > allowed for that
> > > +		 * lane configuration."
> > > +		 *
> > > +		 * Note that we use the max clock and lane count
> > > for eDP 1.3 and
> > > +		 * earlier, and fast vs. wide is irrelevant.
> > > +		 */
> 
> This is where I got hung up on *many* eDP panels. This will break
> many
> pre edp 1.4 panels. I wrapped mine on a DPCD compare to DP_DPCD_REV.
disregard this statement missed the second conditional
> > > +		if (!intel_dp_compute_link_config_fast(intel_dp,
> > > pipe_config,
> > > +						       &limits))
> > > +			return false;
> > > +	} else {
> > > +		/* Optimize for slow and wide. */
> > > +		if (!intel_dp_compute_link_config_wide(intel_dp,
> > > pipe_config,
> > > +						       &limits))
> > > +			return false;
> > > +	}
> > >  
> > >  	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
> > >  		      pipe_config->lane_count, pipe_config-
> > > > port_clock,
> > > 
> > > -- 
> > > 2.11.0
> > > 
> 
> I'm honestly glad that someone else cares I know in the case of the
> wide optimization on a product I was working one we saved 200 uW, I'm
> hoping for a bigger share with the narrow/fast implementation.
> 
> -Matt
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow
  2018-05-09  7:13 [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow Jani Nikula
                   ` (2 preceding siblings ...)
  2018-05-09 12:21 ` [RFC] " Rodrigo Vivi
@ 2018-05-09 18:58 ` Manasi Navare
  3 siblings, 0 replies; 7+ messages in thread
From: Manasi Navare @ 2018-05-09 18:58 UTC (permalink / raw)
  To: Jani Nikula; +Cc: intel-gfx, Rodrigo Vivi

On Wed, May 09, 2018 at 10:13:21AM +0300, Jani Nikula wrote:
> We've opted to use the maximum link rate and lane count for eDP panels,
> because typically the maximum supported configuration reported by the
> panel has matched the native resolution requirements of the panel, and
> optimizing the link has lead to problems.
> 
> With eDP 1.4 rate select method and DSC features, this is decreasingly
> the case. There's a need to optimize the link parameters. Moreover,
> already eDP 1.3 states fast link with fewer lanes is preferred over the
> wide and slow. (Wide and slow should still be more reliable for longer
> cable lengths.)
> 
> Additionally, there have been reports of panels failing on arbitrary
> link configurations, although arguably all configurations they claim to
> support should work.
> 
> Optimize eDP 1.4+ link config fast and narrow.
> 
> Side note: The implementation has a near duplicate of the link config
> function, with just the two inner for loops turned inside out. Perhaps
> there'd be a way to make this, say, more table driven to reduce the
> duplication, but seems like that would lead to duplication in the table
> generation. We'll also have to see how the link config optimization for
> DSC turns out.

Yes for DSC for eDP we currently try fast and wide and if that doesnt
fit the requested mode then we enable DSC.
Now with the fast and narrow approach, again for power savings we can try
the fastest link rate with narrowest lane count and see if DSC can be enabled
there before increasing the lane count. But anyways that calls for a separate
optimization discussion.

Otherwise yes this method looks correct as per eDP 1.4 spec.

> 
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Manasi Navare <manasi.d.navare@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> Untested. It's possible this helps the referenced bug. The downside is
> that this patch has a bunch of dependencies that are too much to
> backport to stable kernels. If the patch works, we may need to consider
> hacking together an uglier backport.
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 73 ++++++++++++++++++++++++++++++++++-------
>  1 file changed, 62 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..1ec62965ece3 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1768,6 +1768,42 @@ intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
>  	return false;
>  }
>  
> +/* Optimize link config in order: max bpp, min lanes, min clock */
> +static bool
> +intel_dp_compute_link_config_fast(struct intel_dp *intel_dp,
> +				  struct intel_crtc_state *pipe_config,
> +				  const struct link_config_limits *limits)

Should we make the name of this function intel_dp_compute_link_config_fast_narrow() to make it
more intuitive to the optimization approach

And while at it change the other one also to _wide_slow()?
Just a suggestion but otherwise everything else LGTM.

Regards
Manasi

> +{
> +	struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
> +	int bpp, clock, lane_count;
> +	int mode_rate, link_clock, link_avail;
> +
> +	for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) {
> +		mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock,
> +						   bpp);
> +
> +		for (lane_count = limits->min_lane_count;
> +		     lane_count <= limits->max_lane_count;
> +		     lane_count <<= 1) {
> +			for (clock = limits->min_clock; clock <= limits->max_clock; clock++) {
> +				link_clock = intel_dp->common_rates[clock];
> +				link_avail = intel_dp_max_data_rate(link_clock,
> +								    lane_count);
> +
> +				if (mode_rate <= link_avail) {
> +					pipe_config->lane_count = lane_count;
> +					pipe_config->pipe_bpp = bpp;
> +					pipe_config->port_clock = link_clock;
> +
> +					return true;
> +				}
> +			}
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static bool
>  intel_dp_compute_link_config(struct intel_encoder *encoder,
>  			     struct intel_crtc_state *pipe_config)
> @@ -1792,13 +1828,15 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  	limits.min_bpp = 6 * 3;
>  	limits.max_bpp = intel_dp_compute_bpp(intel_dp, pipe_config);
>  
> -	if (intel_dp_is_edp(intel_dp)) {
> +	if (intel_dp_is_edp(intel_dp) && intel_dp->edp_dpcd[0] < DP_EDP_14) {
>  		/*
>  		 * Use the maximum clock and number of lanes the eDP panel
> -		 * advertizes being capable of. The panels are generally
> -		 * designed to support only a single clock and lane
> -		 * configuration, and typically these values correspond to the
> -		 * native resolution of the panel.
> +		 * advertizes being capable of. The eDP 1.3 and earlier panels
> +		 * are generally designed to support only a single clock and
> +		 * lane configuration, and typically these values correspond to
> +		 * the native resolution of the panel. With eDP 1.4 rate select
> +		 * and DSC, this is decreasingly the case, and we need to be
> +		 * able to select less than maximum link config.
>  		 */
>  		limits.min_lane_count = limits.max_lane_count;
>  		limits.min_clock = limits.max_clock;
> @@ -1812,12 +1850,25 @@ intel_dp_compute_link_config(struct intel_encoder *encoder,
>  		      intel_dp->common_rates[limits.max_clock],
>  		      limits.max_bpp, adjusted_mode->crtc_clock);
>  
> -	/*
> -	 * Optimize for slow and wide. This is the place to add alternative
> -	 * optimization policy.
> -	 */
> -	if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config, &limits))
> -		return false;
> +	if (intel_dp_is_edp(intel_dp)) {
> +		/*
> +		 * Optimize for fast and narrow. eDP 1.3 section 3.3 and eDP 1.4
> +		 * section A.1: "It is recommended that the minimum number of
> +		 * lanes be used, using the minimum link rate allowed for that
> +		 * lane configuration."
> +		 *
> +		 * Note that we use the max clock and lane count for eDP 1.3 and
> +		 * earlier, and fast vs. wide is irrelevant.
> +		 */
> +		if (!intel_dp_compute_link_config_fast(intel_dp, pipe_config,
> +						       &limits))
> +			return false;
> +	} else {
> +		/* Optimize for slow and wide. */
> +		if (!intel_dp_compute_link_config_wide(intel_dp, pipe_config,
> +						       &limits))
> +			return false;
> +	}
>  
>  	DRM_DEBUG_KMS("DP lane count %d clock %d bpp %d\n",
>  		      pipe_config->lane_count, pipe_config->port_clock,
> -- 
> 2.11.0
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2018-05-09 18:55 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-09  7:13 [RFC] drm/i915/dp: optimize eDP 1.4+ link config fast and narrow Jani Nikula
2018-05-09  8:35 ` ✓ Fi.CI.BAT: success for " Patchwork
2018-05-09 10:08 ` ✓ Fi.CI.IGT: " Patchwork
2018-05-09 12:21 ` [RFC] " Rodrigo Vivi
2018-05-09 15:09   ` Atwood, Matthew S
2018-05-09 15:30     ` Atwood, Matthew S
2018-05-09 18:58 ` Manasi Navare

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.