[PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Manasi Navare]

In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.

In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.

Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++++++++++++++++---------
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..bcccef1 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -328,14 +328,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 	return;
 
  failure_handling:
-	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
-		      intel_connector->base.base.id,
-		      intel_connector->base.name,
-		      intel_dp->link_rate, intel_dp->lane_count);
-	if (!intel_dp_get_link_train_fallback_values(intel_dp,
-						     intel_dp->link_rate,
-						     intel_dp->lane_count))
-		/* Schedule a Hotplug Uevent to userspace to start modeset */
-		schedule_work(&intel_connector->modeset_retry_work);
+	/* Dont fallback and prune modes if its eDP */
+	if (!intel_dp_is_edp(intel_dp)) {
+		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
+			      intel_connector->base.base.id,
+			      intel_connector->base.name,
+			      intel_dp->link_rate, intel_dp->lane_count);
+		if (!intel_dp_get_link_train_fallback_values(intel_dp,
+							     intel_dp->link_rate,
+							     intel_dp->lane_count))
+			/* Schedule a Hotplug Uevent to userspace to start modeset */
+			schedule_work(&intel_connector->modeset_retry_work);
+	} else
+		DRM_ERROR("eDP [CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
+			  intel_connector->base.base.id,
+			  intel_connector->base.name,
+			  intel_dp->link_rate, intel_dp->lane_count);
 	return;
 }
-- 
2.1.4

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

✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Do not do link training fallback or prune modes on EDP
URL   : https://patchwork.freedesktop.org/series/31776/
State : success

== Summary ==

Series 31776v1 drm/i915/edp: Do not do link training fallback or prune modes on EDP
https://patchwork.freedesktop.org/api/1.0/series/31776/revisions/1/mbox/

Test gem_close_race:
        Subgroup basic-threads:
                dmesg-warn -> PASS       (fi-snb-2520m)
Test gem_exec_parallel:
        Subgroup basic:
                pass       -> FAIL       (fi-ilk-650) fdo#101735
Test gem_ringfill:
        Subgroup basic-default-hang:
                incomplete -> DMESG-WARN (fi-blb-e6850) fdo#101600
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-a:
                incomplete -> PASS       (fi-kbl-7567u)

fdo#101735 https://bugs.freedesktop.org/show_bug.cgi?id=101735
fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:458s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:474s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:396s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:568s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:288s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:525s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:517s
fi-byt-j1900     total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  time:541s
fi-byt-n2820     total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  time:526s
fi-cfl-s         total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  time:563s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:432s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:276s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:598s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:445s
fi-ilk-650       total:289  pass:227  dwarn:0   dfail:0   fail:1   skip:61  time:465s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:508s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:475s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:508s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:584s
fi-kbl-7567u     total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  time:491s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:598s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:665s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:470s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:659s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:532s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:568s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:471s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:594s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:431s

6a96415ec560527f41089b246c06e7fd75991791 drm-tip: 2017y-10m-11d-19h-08m-29s UTC integration manifest
cddc893fb88c drm/i915/edp: Do not do link training fallback or prune modes on EDP

== Logs ==

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

✗ Fi.CI.IGT: failure for drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Do not do link training fallback or prune modes on EDP
URL   : https://patchwork.freedesktop.org/series/31776/
State : failure

== Summary ==

Test kms_setmode:
        Subgroup basic:
                pass       -> FAIL       (shard-hsw) fdo#99912
Test kms_flip:
        Subgroup flip-vs-rmfb:
                dmesg-warn -> PASS       (shard-hsw) fdo#102614
Test kms_frontbuffer_tracking:
        Subgroup fbc-1p-primscrn-pri-indfb-draw-mmap-wc:
                pass       -> SKIP       (shard-hsw)
Test kms_atomic_transition:
        Subgroup plane-all-transition-nonblocking-fencing:
                pass       -> FAIL       (shard-hsw)

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614

shard-hsw        total:2552 pass:1438 dwarn:0   dfail:0   fail:10  skip:1104 time:9714s

== Logs ==

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

Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Ville Syrjälä]

On Wed, Oct 11, 2017 at 04:19:45PM -0700, Manasi Navare wrote:
> In case of eDP because the panel has a fixed mode, the link rate
> and lane count at which it is trained corresponds to the link BW
> required to support the native resolution of the panel. In case of
> panles with lower resolutions where fewer lanes are hooked up internally,
> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> So it is pointless to fallback to lower link rate/lane count in case
> of link training failure on eDP connector since the lower link BW
> will not support the native resolution of the panel and we cannot
> prune the preferred mode on the eDP connector.
> 
> In case of Link training failure on the eDP panel, something is wrong
> in the HW internally and hence driver errors out with a loud
> and clear DRM_ERROR message.
> 
> Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> Cc: Jim Bride <jim.bride@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++++++++++++++++---------
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..bcccef1 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -328,14 +328,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>  	return;
>  
>   failure_handling:
> -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> -		      intel_connector->base.base.id,
> -		      intel_connector->base.name,
> -		      intel_dp->link_rate, intel_dp->lane_count);
> -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> -						     intel_dp->link_rate,
> -						     intel_dp->lane_count))
> -		/* Schedule a Hotplug Uevent to userspace to start modeset */
> -		schedule_work(&intel_connector->modeset_retry_work);
> +	/* Dont fallback and prune modes if its eDP */
> +	if (!intel_dp_is_edp(intel_dp)) {
> +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> +			      intel_connector->base.base.id,
> +			      intel_connector->base.name,
> +			      intel_dp->link_rate, intel_dp->lane_count);
> +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
> +							     intel_dp->link_rate,
> +							     intel_dp->lane_count))
> +			/* Schedule a Hotplug Uevent to userspace to start modeset */
> +			schedule_work(&intel_connector->modeset_retry_work);
> +	} else

{} missing around the else. The conventio is to put {} around every
branch if at least one branch needs them.

> +		DRM_ERROR("eDP [CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
                           ^^^
That's redundant since the connector name will alrady say "eDP-<something>"

Apart from that this seems better than blindly pruning the panel's
native mode. If we ever hit this on real hardware we may have to think
about your other idea of trying to reduce the link params in a way
that doesn't result the loss of the native mode.

With the redundant stuff in the error message dropped and {} added this is
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> +			  intel_connector->base.base.id,
> +			  intel_connector->base.name,
> +			  intel_dp->link_rate, intel_dp->lane_count);
>  	return;
>  }
> -- 
> 2.1.4

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Manasi Navare]

On Thu, Oct 12, 2017 at 08:37:10PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 11, 2017 at 04:19:45PM -0700, Manasi Navare wrote:
> > In case of eDP because the panel has a fixed mode, the link rate
> > and lane count at which it is trained corresponds to the link BW
> > required to support the native resolution of the panel. In case of
> > panles with lower resolutions where fewer lanes are hooked up internally,
> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > So it is pointless to fallback to lower link rate/lane count in case
> > of link training failure on eDP connector since the lower link BW
> > will not support the native resolution of the panel and we cannot
> > prune the preferred mode on the eDP connector.
> > 
> > In case of Link training failure on the eDP panel, something is wrong
> > in the HW internally and hence driver errors out with a loud
> > and clear DRM_ERROR message.
> > 
> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> > Cc: Jim Bride <jim.bride@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++++++++++++++++---------
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..bcccef1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -328,14 +328,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> >  	return;
> >  
> >   failure_handling:
> > -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > -		      intel_connector->base.base.id,
> > -		      intel_connector->base.name,
> > -		      intel_dp->link_rate, intel_dp->lane_count);
> > -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > -						     intel_dp->link_rate,
> > -						     intel_dp->lane_count))
> > -		/* Schedule a Hotplug Uevent to userspace to start modeset */
> > -		schedule_work(&intel_connector->modeset_retry_work);
> > +	/* Dont fallback and prune modes if its eDP */
> > +	if (!intel_dp_is_edp(intel_dp)) {
> > +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > +			      intel_connector->base.base.id,
> > +			      intel_connector->base.name,
> > +			      intel_dp->link_rate, intel_dp->lane_count);
> > +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +							     intel_dp->link_rate,
> > +							     intel_dp->lane_count))
> > +			/* Schedule a Hotplug Uevent to userspace to start modeset */
> > +			schedule_work(&intel_connector->modeset_retry_work);
> > +	} else
> 
> {} missing around the else. The conventio is to put {} around every
> branch if at least one branch needs them.
> 
> > +		DRM_ERROR("eDP [CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>                            ^^^
> That's redundant since the connector name will alrady say "eDP-<something>"
> 
> Apart from that this seems better than blindly pruning the panel's
> native mode. If we ever hit this on real hardware we may have to think
> about your other idea of trying to reduce the link params in a way
> that doesn't result the loss of the native mode.
>

Yes I agree. I started coding that logic at first but it becomes a little
bit of a stretch considering the fact that we should never run into that
situation.
So I agree that unless we actually see this on a real HW we should just avoid lowering
link rate/lane count.
 
> With the redundant stuff in the error message dropped and {} added this is
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>

Thanks for the review comments. Yes i will fix the debug message and add the necessary {}.

Manasi
 
> > +			  intel_connector->base.base.id,
> > +			  intel_connector->base.name,
> > +			  intel_dp->link_rate, intel_dp->lane_count);
> >  	return;
> >  }
> > -- 
> > 2.1.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Manasi Navare]

In case of eDP because the panel has a fixed mode, the link rate
and lane count at which it is trained corresponds to the link BW
required to support the native resolution of the panel. In case of
panles with lower resolutions where fewer lanes are hooked up internally,
that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
So it is pointless to fallback to lower link rate/lane count in case
of link training failure on eDP connector since the lower link BW
will not support the native resolution of the panel and we cannot
prune the preferred mode on the eDP connector.

In case of Link training failure on the eDP panel, something is wrong
in the HW internally and hence driver errors out with a loud
and clear DRM_ERROR message.

v2:
* Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)

Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 05907fa..cf8fef8 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
 	return;
 
  failure_handling:
-	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
-		      intel_connector->base.base.id,
-		      intel_connector->base.name,
-		      intel_dp->link_rate, intel_dp->lane_count);
-	if (!intel_dp_get_link_train_fallback_values(intel_dp,
-						     intel_dp->link_rate,
-						     intel_dp->lane_count))
-		/* Schedule a Hotplug Uevent to userspace to start modeset */
-		schedule_work(&intel_connector->modeset_retry_work);
+	/* Dont fallback and prune modes if its eDP */
+	if (!intel_dp_is_edp(intel_dp)) {
+		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
+			      intel_connector->base.base.id,
+			      intel_connector->base.name,
+			      intel_dp->link_rate, intel_dp->lane_count);
+		if (!intel_dp_get_link_train_fallback_values(intel_dp,
+							     intel_dp->link_rate,
+							     intel_dp->lane_count))
+			/* Schedule a Hotplug Uevent to userspace to start modeset */
+			schedule_work(&intel_connector->modeset_retry_work);
+	} else {
+		DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
+			  intel_connector->base.base.id,
+			  intel_connector->base.name,
+			  intel_dp->link_rate, intel_dp->lane_count);
+	}
 	return;
 }
-- 
2.1.4

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

✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2)
URL   : https://patchwork.freedesktop.org/series/31776/
State : success

== Summary ==

Series 31776v2 drm/i915/edp: Do not do link training fallback or prune modes on EDP
https://patchwork.freedesktop.org/api/1.0/series/31776/revisions/2/mbox/

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:450s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:466s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:388s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:570s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:285s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:528s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:530s
fi-byt-j1900     total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  time:544s
fi-byt-n2820     total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  time:533s
fi-cfl-s         total:289  pass:253  dwarn:4   dfail:0   fail:0   skip:32  time:558s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:431s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:274s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:599s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:442s
fi-ilk-650       total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  time:468s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:507s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:479s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:508s
fi-kbl-7567u     total:289  pass:265  dwarn:4   dfail:0   fail:0   skip:20  time:483s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:599s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:663s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:472s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:665s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:542s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:522s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:474s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:590s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:432s

96f680c12769fd0f777e569e9f44b26db9450cfd drm-tip: 2017y-10m-12d-18h-32m-23s UTC integration manifest
f37527f367e6 drm/i915/edp: Do not do link training fallback or prune modes on EDP

== Logs ==

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

✗ Fi.CI.IGT: failure for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2)
URL   : https://patchwork.freedesktop.org/series/31776/
State : failure

== Summary ==

Test gem_userptr_blits:
        Subgroup sync-unmap-cycles:
                dmesg-warn -> PASS       (shard-hsw)
Test kms_render:
        Subgroup direct-render:
                dmesg-warn -> PASS       (shard-hsw)
Test kms_setmode:
        Subgroup basic:
                fail       -> PASS       (shard-hsw) fdo#99912
Test kms_plane:
        Subgroup plane-panning-bottom-right-suspend-pipe-B-planes:
                pass       -> SKIP       (shard-hsw)
Test kms_pwrite_crc:
                pass       -> SKIP       (shard-hsw)
Test prime_self_import:
        Subgroup export-vs-gem_close-race:
                pass       -> FAIL       (shard-hsw)

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hsw        total:2552 pass:1437 dwarn:1   dfail:0   fail:9   skip:1105 time:9589s

== Logs ==

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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> In case of eDP because the panel has a fixed mode, the link rate
> and lane count at which it is trained corresponds to the link BW
> required to support the native resolution of the panel. In case of
> panles with lower resolutions where fewer lanes are hooked up internally,
> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> So it is pointless to fallback to lower link rate/lane count in case
> of link training failure on eDP connector since the lower link BW
> will not support the native resolution of the panel and we cannot
> prune the preferred mode on the eDP connector.
> 
> In case of Link training failure on the eDP panel, something is wrong
> in the HW internally and hence driver errors out with a loud
> and clear DRM_ERROR message.
> 
> v2:
> * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> 
> Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> Cc: Jim Bride <jim.bride@linux.intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>

This fell through the cracks, looks like it partially fixes
https://bugs.freedesktop.org/show_bug.cgi?id=103369

Why link training fails there is not clear.

> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++++++++++++++++---------
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 05907fa..cf8fef8 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>  	return;
>  
>   failure_handling:
> -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> -		      intel_connector->base.base.id,
> -		      intel_connector->base.name,
> -		      intel_dp->link_rate, intel_dp->lane_count);
> -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> -						     intel_dp->link_rate,
> -						     intel_dp->lane_count))
> -		/* Schedule a Hotplug Uevent to userspace to start modeset */
> -		schedule_work(&intel_connector->modeset_retry_work);
> +	/* Dont fallback and prune modes if its eDP */
> +	if (!intel_dp_is_edp(intel_dp)) {
> +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> +			      intel_connector->base.base.id,
> +			      intel_connector->base.name,
> +			      intel_dp->link_rate, intel_dp->lane_count);
> +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
> +							     intel_dp->link_rate,
> +							     intel_dp->lane_count))
> +			/* Schedule a Hotplug Uevent to userspace to start modeset */
> +			schedule_work(&intel_connector->modeset_retry_work);
> +	} else {
> +		DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> +			  intel_connector->base.base.id,
> +			  intel_connector->base.name,
> +			  intel_dp->link_rate, intel_dp->lane_count);
> +	}
>  	return;
>  }
> -- 
> 2.1.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> > In case of eDP because the panel has a fixed mode, the link rate
> > and lane count at which it is trained corresponds to the link BW
> > required to support the native resolution of the panel. In case of
> > panles with lower resolutions where fewer lanes are hooked up internally,
> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > So it is pointless to fallback to lower link rate/lane count in case
> > of link training failure on eDP connector since the lower link BW
> > will not support the native resolution of the panel and we cannot
> > prune the preferred mode on the eDP connector.
> > 
> > In case of Link training failure on the eDP panel, something is wrong
> > in the HW internally and hence driver errors out with a loud
> > and clear DRM_ERROR message.
> > 
> > v2:
> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> > 
> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> > Cc: Jim Bride <jim.bride@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
> 
> This fell through the cracks, looks like it partially fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> 
> Why link training fails there is not clear.

Ok, the link training fail turned out to be a race between a modeset
link training and a link retraining called from
runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
one was fixed meanwhile by

commit 42e5e65765265485ecf2a480c244d76c2c624449
Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Mon Nov 13 17:01:40 2017 +0100
Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
CommitDate: Thu Nov 23 14:59:07 2017 +0100

    drm/i915: sync dp link status checks against atomic commmits

I merged now this fix to address the other issue, adding the above bug
as reference. Thanks for the patch and the review.

--Imre

> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++++++++++++++++---------
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..cf8fef8 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> >  	return;
> >  
> >   failure_handling:
> > -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > -		      intel_connector->base.base.id,
> > -		      intel_connector->base.name,
> > -		      intel_dp->link_rate, intel_dp->lane_count);
> > -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > -						     intel_dp->link_rate,
> > -						     intel_dp->lane_count))
> > -		/* Schedule a Hotplug Uevent to userspace to start modeset */
> > -		schedule_work(&intel_connector->modeset_retry_work);
> > +	/* Dont fallback and prune modes if its eDP */
> > +	if (!intel_dp_is_edp(intel_dp)) {
> > +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > +			      intel_connector->base.base.id,
> > +			      intel_connector->base.name,
> > +			      intel_dp->link_rate, intel_dp->lane_count);
> > +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +							     intel_dp->link_rate,
> > +							     intel_dp->lane_count))
> > +			/* Schedule a Hotplug Uevent to userspace to start modeset */
> > +			schedule_work(&intel_connector->modeset_retry_work);
> > +	} else {
> > +		DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > +			  intel_connector->base.base.id,
> > +			  intel_connector->base.name,
> > +			  intel_dp->link_rate, intel_dp->lane_count);
> > +	}
> >  	return;
> >  }
> > -- 
> > 2.1.4
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Jani Nikula]

On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>> > In case of eDP because the panel has a fixed mode, the link rate
>> > and lane count at which it is trained corresponds to the link BW
>> > required to support the native resolution of the panel. In case of
>> > panles with lower resolutions where fewer lanes are hooked up internally,
>> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>> > So it is pointless to fallback to lower link rate/lane count in case
>> > of link training failure on eDP connector since the lower link BW
>> > will not support the native resolution of the panel and we cannot
>> > prune the preferred mode on the eDP connector.
>> > 
>> > In case of Link training failure on the eDP panel, something is wrong
>> > in the HW internally and hence driver errors out with a loud
>> > and clear DRM_ERROR message.
>> > 
>> > v2:
>> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>> > 
>> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
>> > Cc: Jim Bride <jim.bride@linux.intel.com>
>> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>> > Cc: Dave Airlie <airlied@redhat.com>
>> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
>> > Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
>> 
>> This fell through the cracks, looks like it partially fixes
>> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>> 
>> Why link training fails there is not clear.
>
> Ok, the link training fail turned out to be a race between a modeset
> link training and a link retraining called from
> runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> one was fixed meanwhile by
>
> commit 42e5e65765265485ecf2a480c244d76c2c624449
> Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
> AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
> CommitDate: Thu Nov 23 14:59:07 2017 +0100
>
>     drm/i915: sync dp link status checks against atomic commmits
>
> I merged now this fix to address the other issue, adding the above bug
> as reference. Thanks for the patch and the review.

Thanks for the follow-up... but should we have added a Fixes: or cc:
stable tag here?

BR,
Jani.


>
> --Imre
>
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 +++++++++++++++++---------
>> >  1 file changed, 17 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > index 05907fa..cf8fef8 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>> >  	return;
>> >  
>> >   failure_handling:
>> > -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>> > -		      intel_connector->base.base.id,
>> > -		      intel_connector->base.name,
>> > -		      intel_dp->link_rate, intel_dp->lane_count);
>> > -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
>> > -						     intel_dp->link_rate,
>> > -						     intel_dp->lane_count))
>> > -		/* Schedule a Hotplug Uevent to userspace to start modeset */
>> > -		schedule_work(&intel_connector->modeset_retry_work);
>> > +	/* Dont fallback and prune modes if its eDP */
>> > +	if (!intel_dp_is_edp(intel_dp)) {
>> > +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>> > +			      intel_connector->base.base.id,
>> > +			      intel_connector->base.name,
>> > +			      intel_dp->link_rate, intel_dp->lane_count);
>> > +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
>> > +							     intel_dp->link_rate,
>> > +							     intel_dp->lane_count))
>> > +			/* Schedule a Hotplug Uevent to userspace to start modeset */
>> > +			schedule_work(&intel_connector->modeset_retry_work);
>> > +	} else {
>> > +		DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>> > +			  intel_connector->base.base.id,
>> > +			  intel_connector->base.name,
>> > +			  intel_dp->link_rate, intel_dp->lane_count);
>> > +	}
>> >  	return;
>> >  }
>> > -- 
>> > 2.1.4
>> > 
>> > _______________________________________________
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Imre Deak]

On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
> On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
> > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> >> > In case of eDP because the panel has a fixed mode, the link rate
> >> > and lane count at which it is trained corresponds to the link BW
> >> > required to support the native resolution of the panel. In case of
> >> > panles with lower resolutions where fewer lanes are hooked up internally,
> >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> >> > So it is pointless to fallback to lower link rate/lane count in case
> >> > of link training failure on eDP connector since the lower link BW
> >> > will not support the native resolution of the panel and we cannot
> >> > prune the preferred mode on the eDP connector.
> >> > 
> >> > In case of Link training failure on the eDP panel, something is wrong
> >> > in the HW internally and hence driver errors out with a loud
> >> > and clear DRM_ERROR message.
> >> > 
> >> > v2:
> >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> >> > 
> >> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> >> > Cc: Jim Bride <jim.bride@linux.intel.com>
> >> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> >> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> >> > Cc: Dave Airlie <airlied@redhat.com>
> >> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> >> > Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
> >> 
> >> This fell through the cracks, looks like it partially fixes
> >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> >> 
> >> Why link training fails there is not clear.
> >
> > Ok, the link training fail turned out to be a race between a modeset
> > link training and a link retraining called from
> > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> > one was fixed meanwhile by
> >
> > commit 42e5e65765265485ecf2a480c244d76c2c624449
> > Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
> > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> > Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
> > CommitDate: Thu Nov 23 14:59:07 2017 +0100
> >
> >     drm/i915: sync dp link status checks against atomic commmits
> >
> > I merged now this fix to address the other issue, adding the above bug
> > as reference. Thanks for the patch and the review.
> 
> Thanks for the follow-up... but should we have added a Fixes: or cc:
> stable tag here?

Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
training failure")

I wasn't sure about stable, since for me the link training failure
happened only due to the bug fixed by 42e5e65765265. In any case I can't
see how it could cause problems, so yes let's Cc: stable too.

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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Manasi Navare]

On Tue, Jan 23, 2018 at 02:57:04PM +0200, Imre Deak wrote:
> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
> > On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
> > > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> > >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> > >> > In case of eDP because the panel has a fixed mode, the link rate
> > >> > and lane count at which it is trained corresponds to the link BW
> > >> > required to support the native resolution of the panel. In case of
> > >> > panles with lower resolutions where fewer lanes are hooked up internally,
> > >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > >> > So it is pointless to fallback to lower link rate/lane count in case
> > >> > of link training failure on eDP connector since the lower link BW
> > >> > will not support the native resolution of the panel and we cannot
> > >> > prune the preferred mode on the eDP connector.
> > >> > 
> > >> > In case of Link training failure on the eDP panel, something is wrong
> > >> > in the HW internally and hence driver errors out with a loud
> > >> > and clear DRM_ERROR message.
> > >> > 
> > >> > v2:
> > >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> > >> > 
> > >> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> > >> > Cc: Jim Bride <jim.bride@linux.intel.com>
> > >> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > >> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > >> > Cc: Dave Airlie <airlied@redhat.com>
> > >> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > >> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > >> > Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
> > >> 
> > >> This fell through the cracks, looks like it partially fixes
> > >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> > >> 
> > >> Why link training fails there is not clear.
> > >
> > > Ok, the link training fail turned out to be a race between a modeset
> > > link training and a link retraining called from
> > > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> > > one was fixed meanwhile by
> > >
> > > commit 42e5e65765265485ecf2a480c244d76c2c624449
> > > Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
> > > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> > > Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
> > > CommitDate: Thu Nov 23 14:59:07 2017 +0100
> > >
> > >     drm/i915: sync dp link status checks against atomic commmits
> > >
> > > I merged now this fix to address the other issue, adding the above bug
> > > as reference. Thanks for the patch and the review.
> > 
> > Thanks for the follow-up... but should we have added a Fixes: or cc:
> > stable tag here?
> 
> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
> training failure")
> 
> I wasn't sure about stable, since for me the link training failure
> happened only due to the bug fixed by 42e5e65765265. In any case I can't
> see how it could cause problems, so yes let's Cc: stable too.
> 
> --Imre

Thanks for your feedback Imre and Jani.
This patch avoids fallback and modeset retry for link train failure on edp.
But lately we have seen a bunch of buggy panels that require just another modeset
at same link params to pass link training.
So one idea I had and as suggested by DK was that we try harder before failing on eDP.

So I was planning to add this code:
On eDP, if link train fails -> power cycle the panel -> Just call modeset retry function
without fallback -> send a uevent for modeset retry.

What do you think?

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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Jani Nikula]

On Tue, 23 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>> On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
>> > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>> >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>> >> > In case of eDP because the panel has a fixed mode, the link rate
>> >> > and lane count at which it is trained corresponds to the link BW
>> >> > required to support the native resolution of the panel. In case of
>> >> > panles with lower resolutions where fewer lanes are hooked up internally,
>> >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>> >> > So it is pointless to fallback to lower link rate/lane count in case
>> >> > of link training failure on eDP connector since the lower link BW
>> >> > will not support the native resolution of the panel and we cannot
>> >> > prune the preferred mode on the eDP connector.
>> >> > 
>> >> > In case of Link training failure on the eDP panel, something is wrong
>> >> > in the HW internally and hence driver errors out with a loud
>> >> > and clear DRM_ERROR message.
>> >> > 
>> >> > v2:
>> >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>> >> > 
>> >> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
>> >> > Cc: Jim Bride <jim.bride@linux.intel.com>
>> >> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
>> >> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>> >> > Cc: Dave Airlie <airlied@redhat.com>
>> >> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> >> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
>> >> > Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
>> >> 
>> >> This fell through the cracks, looks like it partially fixes
>> >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>> >> 
>> >> Why link training fails there is not clear.
>> >
>> > Ok, the link training fail turned out to be a race between a modeset
>> > link training and a link retraining called from
>> > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
>> > one was fixed meanwhile by
>> >
>> > commit 42e5e65765265485ecf2a480c244d76c2c624449
>> > Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
>> > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
>> > Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
>> > CommitDate: Thu Nov 23 14:59:07 2017 +0100
>> >
>> >     drm/i915: sync dp link status checks against atomic commmits
>> >
>> > I merged now this fix to address the other issue, adding the above bug
>> > as reference. Thanks for the patch and the review.
>> 
>> Thanks for the follow-up... but should we have added a Fixes: or cc:
>> stable tag here?
>
> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
> training failure")
>
> I wasn't sure about stable, since for me the link training failure
> happened only due to the bug fixed by 42e5e65765265. In any case I can't
> see how it could cause problems, so yes let's Cc: stable too.

Rodrigo, here's another one to cherry-pick to drm-intel-next-fixes.

BR,
Jani.


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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Timo Aaltonen]

On 30.01.2018 09:38, Jani Nikula wrote:
> On Tue, 23 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
>> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>>> On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
>>>> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>>>>> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>>>>>> In case of eDP because the panel has a fixed mode, the link rate
>>>>>> and lane count at which it is trained corresponds to the link BW
>>>>>> required to support the native resolution of the panel. In case of
>>>>>> panles with lower resolutions where fewer lanes are hooked up internally,
>>>>>> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>>>>>> So it is pointless to fallback to lower link rate/lane count in case
>>>>>> of link training failure on eDP connector since the lower link BW
>>>>>> will not support the native resolution of the panel and we cannot
>>>>>> prune the preferred mode on the eDP connector.
>>>>>>
>>>>>> In case of Link training failure on the eDP panel, something is wrong
>>>>>> in the HW internally and hence driver errors out with a loud
>>>>>> and clear DRM_ERROR message.
>>>>>>
>>>>>> v2:
>>>>>> * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>>>>>>
>>>>>> Cc: Clinton Taylor <clinton.a.taylor@intel.com>
>>>>>> Cc: Jim Bride <jim.bride@linux.intel.com>
>>>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
>>>>>> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
>>>>>
>>>>> This fell through the cracks, looks like it partially fixes
>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>>>>>
>>>>> Why link training fails there is not clear.
>>>>
>>>> Ok, the link training fail turned out to be a race between a modeset
>>>> link training and a link retraining called from
>>>> runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
>>>> one was fixed meanwhile by
>>>>
>>>> commit 42e5e65765265485ecf2a480c244d76c2c624449
>>>> Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> AuthorDate: Mon Nov 13 17:01:40 2017 +0100
>>>> Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
>>>> CommitDate: Thu Nov 23 14:59:07 2017 +0100
>>>>
>>>>     drm/i915: sync dp link status checks against atomic commmits
>>>>
>>>> I merged now this fix to address the other issue, adding the above bug
>>>> as reference. Thanks for the patch and the review.
>>>
>>> Thanks for the follow-up... but should we have added a Fixes: or cc:
>>> stable tag here?
>>
>> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
>> training failure")
>>
>> I wasn't sure about stable, since for me the link training failure
>> happened only due to the bug fixed by 42e5e65765265. In any case I can't
>> see how it could cause problems, so yes let's Cc: stable too.
> 
> Rodrigo, here's another one to cherry-pick to drm-intel-next-fixes.

This patch fixes a regression with a BIOS upgrade on a Dell machine,
where the screen would stay blank after resume from suspend. So I'd like
it to find it's way to 4.15.x if that's still a thing.


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

Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

[Jani Nikula]

On Thu, 12 Apr 2018, Timo Aaltonen <tjaalton@ubuntu.com> wrote:
> On 30.01.2018 09:38, Jani Nikula wrote:
>> On Tue, 23 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
>>> On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
>>>> On Mon, 22 Jan 2018, Imre Deak <imre.deak@intel.com> wrote:
>>>>> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>>>>>> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>>>>>>> In case of eDP because the panel has a fixed mode, the link rate
>>>>>>> and lane count at which it is trained corresponds to the link BW
>>>>>>> required to support the native resolution of the panel. In case of
>>>>>>> panles with lower resolutions where fewer lanes are hooked up internally,
>>>>>>> that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>>>>>>> So it is pointless to fallback to lower link rate/lane count in case
>>>>>>> of link training failure on eDP connector since the lower link BW
>>>>>>> will not support the native resolution of the panel and we cannot
>>>>>>> prune the preferred mode on the eDP connector.
>>>>>>>
>>>>>>> In case of Link training failure on the eDP panel, something is wrong
>>>>>>> in the HW internally and hence driver errors out with a loud
>>>>>>> and clear DRM_ERROR message.
>>>>>>>
>>>>>>> v2:
>>>>>>> * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>>>>>>>
>>>>>>> Cc: Clinton Taylor <clinton.a.taylor@intel.com>
>>>>>>> Cc: Jim Bride <jim.bride@linux.intel.com>
>>>>>>> Cc: Jani Nikula <jani.nikula@linux.intel.com>
>>>>>>> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
>>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>>>> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
>>>>>>> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
>>>>>>
>>>>>> This fell through the cracks, looks like it partially fixes
>>>>>> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>>>>>>
>>>>>> Why link training fails there is not clear.
>>>>>
>>>>> Ok, the link training fail turned out to be a race between a modeset
>>>>> link training and a link retraining called from
>>>>> runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
>>>>> one was fixed meanwhile by
>>>>>
>>>>> commit 42e5e65765265485ecf2a480c244d76c2c624449
>>>>> Author:     Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> AuthorDate: Mon Nov 13 17:01:40 2017 +0100
>>>>> Commit:     Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> CommitDate: Thu Nov 23 14:59:07 2017 +0100
>>>>>
>>>>>     drm/i915: sync dp link status checks against atomic commmits
>>>>>
>>>>> I merged now this fix to address the other issue, adding the above bug
>>>>> as reference. Thanks for the patch and the review.
>>>>
>>>> Thanks for the follow-up... but should we have added a Fixes: or cc:
>>>> stable tag here?
>>>
>>> Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
>>> training failure")
>>>
>>> I wasn't sure about stable, since for me the link training failure
>>> happened only due to the bug fixed by 42e5e65765265. In any case I can't
>>> see how it could cause problems, so yes let's Cc: stable too.
>> 
>> Rodrigo, here's another one to cherry-pick to drm-intel-next-fixes.
>
> This patch fixes a regression with a BIOS upgrade on a Dell machine,
> where the screen would stay blank after resume from suspend. So I'd like
> it to find it's way to 4.15.x if that's still a thing.

I made the backport request to v4.13+, up to stable team which kernels
they care about.

BR,
Jani.

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