| Message ID | 1476912593-10019-1-git-send-email-matthew.auld@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Oct 19, 2016 at 10:29:53PM +0100, Matthew Auld wrote: > Currently it's entirely possible to go through the link training step > without first determining the lane_count, which is silly since we end up > doing a bunch of aux transfers of size = 0, as highlighted by > WARN_ON(!msg->buffer != !msg->size), and can only ever result in a > 'failed to update link training' message. This can be observed during > intel_dp_long_pulse where we can do the link training step, but before > we have had a chance to set the link params. To avoid this we add an > extra check for the lane_count in intel_dp_check_link_status, which > should prevent us from doing the link training step prematurely. > > v2: add WARN_ON_ONCE and FIXME comment (Ville) > > References: https://bugs.freedesktop.org/show_bug.cgi?id=97344 > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Mika Kahola <mika.kahola@intel.com> > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > --- > drivers/gpu/drm/i915/intel_dp.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 88f3b74..fb760ad 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp) > if (!to_intel_crtc(intel_encoder->base.crtc)->active) > return; > > + /* FIXME: we need to synchronize this sort of stuff with hardware > + * readout */ > + if (WARN_ON_ONCE(!intel_dp->lane_count)) > + return; One warn is better than a constant spew as can be seen eg. in https://bugs.freedesktop.org/show_bug.cgi?id=98323 Still need to fix the real issue of course, but in the meantime Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > + > /* if link training is requested we should perform it always */ > if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) || > (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) { > -- > 2.7.4
On 19 October 2016 at 22:47, Patchwork <patchwork@emeril.freedesktop.org> wrote: > == Series Details == > > Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) > URL : https://patchwork.freedesktop.org/series/11667/ > State : warning > > == Summary == > > Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status > https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/ > > Test drv_module_reload_basic: > pass -> DMESG-WARN (fi-skl-6700hq) [ 36.849247] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 36.849278] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B [ 36.867178] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [ 38.946464] Setting dangerous option inject_load_failure - tainting kernel [ 39.093675] Setting dangerous option inject_load_failure - tainting kernel [ 39.258529] Setting dangerous option inject_load_failure - tainting kernel [ 39.424800] Setting dangerous option inject_load_failure - tainting kernel [ 40.497909] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 40.498321] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B [ 40.530092] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=98353 > Test gem_exec_suspend: > Subgroup basic-s3: > dmesg-warn -> PASS (fi-skl-6700hq) > Test kms_pipe_crc_basic: > Subgroup nonblocking-crc-pipe-a: > dmesg-warn -> PASS (fi-ilk-650) > Subgroup nonblocking-crc-pipe-b: > pass -> DMESG-WARN (fi-ivb-3770) [ 391.061781] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 [ 391.062331] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 https://bugs.freedesktop.org/show_bug.cgi?id=98228
On Thu, Oct 20, 2016 at 10:39:57AM +0100, Matthew Auld wrote: > On 19 October 2016 at 22:47, Patchwork <patchwork@emeril.freedesktop.org> wrote: > > == Series Details == > > > > Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2) > > URL : https://patchwork.freedesktop.org/series/11667/ > > State : warning > > > > == Summary == > > > > Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status > > https://patchwork.freedesktop.org/api/1.0/series/11667/revisions/2/mbox/ > > > > Test drv_module_reload_basic: > > pass -> DMESG-WARN (fi-skl-6700hq) > [ 36.849247] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > [ 36.849278] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B > [ 36.867178] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS > [ 38.946464] Setting dangerous option inject_load_failure - tainting kernel > [ 39.093675] Setting dangerous option inject_load_failure - tainting kernel > [ 39.258529] Setting dangerous option inject_load_failure - tainting kernel > [ 39.424800] Setting dangerous option inject_load_failure - tainting kernel > [ 40.497909] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > [ 40.498321] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B > [ 40.530092] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS > > Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=98353 > > > Test gem_exec_suspend: > > Subgroup basic-s3: > > dmesg-warn -> PASS (fi-skl-6700hq) > > Test kms_pipe_crc_basic: > > Subgroup nonblocking-crc-pipe-a: > > dmesg-warn -> PASS (fi-ilk-650) > > Subgroup nonblocking-crc-pipe-b: > > pass -> DMESG-WARN (fi-ivb-3770) > [ 391.061781] [drm:drm_edid_block_valid] *ERROR* EDID checksum is > invalid, remainder is 130 > [ 391.062331] [drm:drm_edid_block_valid] *ERROR* EDID checksum is > invalid, remainder is 130 > > https://bugs.freedesktop.org/show_bug.cgi?id=98228 Pushed to dinq. Thanks for the patch.
On Thu, 20 Oct 2016, Matthew Auld <matthew.auld@intel.com> wrote: > Currently it's entirely possible to go through the link training step > without first determining the lane_count, which is silly since we end up > doing a bunch of aux transfers of size = 0, as highlighted by > WARN_ON(!msg->buffer != !msg->size), and can only ever result in a > 'failed to update link training' message. This can be observed during > intel_dp_long_pulse where we can do the link training step, but before > we have had a chance to set the link params. To avoid this we add an > extra check for the lane_count in intel_dp_check_link_status, which > should prevent us from doing the link training step prematurely. Now we'll just have to fix the cases where we try to do this anyway: https://bugs.freedesktop.org/show_bug.cgi?id=98374 BR, Jani. > > v2: add WARN_ON_ONCE and FIXME comment (Ville) > > References: https://bugs.freedesktop.org/show_bug.cgi?id=97344 > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Cc: Mika Kahola <mika.kahola@intel.com> > Signed-off-by: Matthew Auld <matthew.auld@intel.com> > --- > drivers/gpu/drm/i915/intel_dp.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 88f3b74..fb760ad 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp) > if (!to_intel_crtc(intel_encoder->base.crtc)->active) > return; > > + /* FIXME: we need to synchronize this sort of stuff with hardware > + * readout */ > + if (WARN_ON_ONCE(!intel_dp->lane_count)) > + return; > + > /* if link training is requested we should perform it always */ > if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) || > (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 88f3b74..fb760ad 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp) if (!to_intel_crtc(intel_encoder->base.crtc)->active) return; + /* FIXME: we need to synchronize this sort of stuff with hardware + * readout */ + if (WARN_ON_ONCE(!intel_dp->lane_count)) + return; + /* if link training is requested we should perform it always */ if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) || (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {
Currently it's entirely possible to go through the link training step without first determining the lane_count, which is silly since we end up doing a bunch of aux transfers of size = 0, as highlighted by WARN_ON(!msg->buffer != !msg->size), and can only ever result in a 'failed to update link training' message. This can be observed during intel_dp_long_pulse where we can do the link training step, but before we have had a chance to set the link params. To avoid this we add an extra check for the lane_count in intel_dp_check_link_status, which should prevent us from doing the link training step prematurely. v2: add WARN_ON_ONCE and FIXME comment (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=97344 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> --- drivers/gpu/drm/i915/intel_dp.c | 5 +++++ 1 file changed, 5 insertions(+)