diff mbox

drm/i915/dp: add lane_count check in intel_dp_check_link_status

Message ID 1476912593-10019-1-git-send-email-matthew.auld@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Matthew Auld Oct. 19, 2016, 9:29 p.m. UTC
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(+)

Comments

Ville Syrjälä Oct. 20, 2016, 8:37 a.m. UTC | #1
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
Matthew Auld Oct. 20, 2016, 9:39 a.m. UTC | #2
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
Ville Syrjälä Oct. 21, 2016, 1:18 p.m. UTC | #3
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.
Jani Nikula Oct. 24, 2016, 2:21 p.m. UTC | #4
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 mbox

Patch

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))) {