* [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP @ 2017-10-11 23:19 Manasi Navare 2017-10-11 23:51 ` ✓ Fi.CI.BAT: success for " Patchwork ` (5 more replies) 0 siblings, 6 replies; 16+ messages in thread From: Manasi Navare @ 2017-10-11 23:19 UTC (permalink / raw) To: intel-gfx; +Cc: Daniel Vetter, Dave Airlie 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare @ 2017-10-11 23:51 ` Patchwork 2017-10-12 6:15 ` ✗ Fi.CI.IGT: failure " Patchwork ` (4 subsequent siblings) 5 siblings, 0 replies; 16+ messages in thread From: Patchwork @ 2017-10-11 23:51 UTC (permalink / raw) To: Manasi Navare; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* ✗ Fi.CI.IGT: failure for drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare 2017-10-11 23:51 ` ✓ Fi.CI.BAT: success for " Patchwork @ 2017-10-12 6:15 ` Patchwork 2017-10-12 17:37 ` [PATCH] " Ville Syrjälä ` (3 subsequent siblings) 5 siblings, 0 replies; 16+ messages in thread From: Patchwork @ 2017-10-12 6:15 UTC (permalink / raw) To: Manasi Navare; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare 2017-10-11 23:51 ` ✓ Fi.CI.BAT: success for " Patchwork 2017-10-12 6:15 ` ✗ Fi.CI.IGT: failure " Patchwork @ 2017-10-12 17:37 ` Ville Syrjälä 2017-10-12 19:05 ` Manasi Navare 2017-10-12 19:13 ` [PATCH v2] " Manasi Navare ` (2 subsequent siblings) 5 siblings, 1 reply; 16+ messages in thread From: Ville Syrjälä @ 2017-10-12 17:37 UTC (permalink / raw) To: Manasi Navare; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-12 17:37 ` [PATCH] " Ville Syrjälä @ 2017-10-12 19:05 ` Manasi Navare 0 siblings, 0 replies; 16+ messages in thread From: Manasi Navare @ 2017-10-12 19:05 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare ` (2 preceding siblings ...) 2017-10-12 17:37 ` [PATCH] " Ville Syrjälä @ 2017-10-12 19:13 ` Manasi Navare 2018-01-19 15:45 ` Imre Deak 2017-10-12 19:37 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) Patchwork 2017-10-13 2:38 ` ✗ Fi.CI.IGT: failure " Patchwork 5 siblings, 1 reply; 16+ messages in thread From: Manasi Navare @ 2017-10-12 19:13 UTC (permalink / raw) To: intel-gfx; +Cc: Daniel Vetter, Dave Airlie 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 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2017-10-12 19:13 ` [PATCH v2] " Manasi Navare @ 2018-01-19 15:45 ` Imre Deak 2018-01-22 16:07 ` Imre Deak 0 siblings, 1 reply; 16+ messages in thread From: Imre Deak @ 2018-01-19 15:45 UTC (permalink / raw) To: Manasi Navare; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-19 15:45 ` Imre Deak @ 2018-01-22 16:07 ` Imre Deak 2018-01-23 9:48 ` Jani Nikula 0 siblings, 1 reply; 16+ messages in thread From: Imre Deak @ 2018-01-22 16:07 UTC (permalink / raw) To: Manasi Navare, Ville Syrjälä Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-22 16:07 ` Imre Deak @ 2018-01-23 9:48 ` Jani Nikula 2018-01-23 12:57 ` Imre Deak 0 siblings, 1 reply; 16+ messages in thread From: Jani Nikula @ 2018-01-23 9:48 UTC (permalink / raw) To: imre.deak, Manasi Navare, Ville Syrjälä Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-23 9:48 ` Jani Nikula @ 2018-01-23 12:57 ` Imre Deak 2018-01-23 22:34 ` Manasi Navare 2018-01-30 7:38 ` Jani Nikula 0 siblings, 2 replies; 16+ messages in thread From: Imre Deak @ 2018-01-23 12:57 UTC (permalink / raw) To: Jani Nikula; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-23 12:57 ` Imre Deak @ 2018-01-23 22:34 ` Manasi Navare 2018-01-30 7:38 ` Jani Nikula 1 sibling, 0 replies; 16+ messages in thread From: Manasi Navare @ 2018-01-23 22:34 UTC (permalink / raw) To: Imre Deak; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-23 12:57 ` Imre Deak 2018-01-23 22:34 ` Manasi Navare @ 2018-01-30 7:38 ` Jani Nikula 2018-04-12 8:11 ` Timo Aaltonen 1 sibling, 1 reply; 16+ messages in thread From: Jani Nikula @ 2018-01-30 7:38 UTC (permalink / raw) To: imre.deak, Rodrigo Vivi; +Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-01-30 7:38 ` Jani Nikula @ 2018-04-12 8:11 ` Timo Aaltonen 2018-04-12 9:10 ` Jani Nikula 0 siblings, 1 reply; 16+ messages in thread From: Timo Aaltonen @ 2018-04-12 8:11 UTC (permalink / raw) To: Jani Nikula, imre.deak, Rodrigo Vivi Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP 2018-04-12 8:11 ` Timo Aaltonen @ 2018-04-12 9:10 ` Jani Nikula 0 siblings, 0 replies; 16+ messages in thread From: Jani Nikula @ 2018-04-12 9:10 UTC (permalink / raw) To: Timo Aaltonen, imre.deak, Rodrigo Vivi Cc: Daniel Vetter, intel-gfx, Dave Airlie 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare ` (3 preceding siblings ...) 2017-10-12 19:13 ` [PATCH v2] " Manasi Navare @ 2017-10-12 19:37 ` Patchwork 2017-10-13 2:38 ` ✗ Fi.CI.IGT: failure " Patchwork 5 siblings, 0 replies; 16+ messages in thread From: Patchwork @ 2017-10-12 19:37 UTC (permalink / raw) To: Manasi Navare; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* ✗ Fi.CI.IGT: failure for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare ` (4 preceding siblings ...) 2017-10-12 19:37 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) Patchwork @ 2017-10-13 2:38 ` Patchwork 5 siblings, 0 replies; 16+ messages in thread From: Patchwork @ 2017-10-13 2:38 UTC (permalink / raw) To: Manasi Navare; +Cc: intel-gfx == 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-04-12 9:09 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare 2017-10-11 23:51 ` ✓ Fi.CI.BAT: success for " Patchwork 2017-10-12 6:15 ` ✗ Fi.CI.IGT: failure " Patchwork 2017-10-12 17:37 ` [PATCH] " Ville Syrjälä 2017-10-12 19:05 ` Manasi Navare 2017-10-12 19:13 ` [PATCH v2] " Manasi Navare 2018-01-19 15:45 ` Imre Deak 2018-01-22 16:07 ` Imre Deak 2018-01-23 9:48 ` Jani Nikula 2018-01-23 12:57 ` Imre Deak 2018-01-23 22:34 ` Manasi Navare 2018-01-30 7:38 ` Jani Nikula 2018-04-12 8:11 ` Timo Aaltonen 2018-04-12 9:10 ` Jani Nikula 2017-10-12 19:37 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) Patchwork 2017-10-13 2:38 ` ✗ Fi.CI.IGT: failure " Patchwork
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.