[PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Matthew Auld]

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.

References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a3c7dd8..0dbb672 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
 		return;
 
+	if (!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))) {
-- 
2.7.4

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

✗ Fi.CI.BAT: failure for drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Patchwork]

== Series Details ==

Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status
URL   : https://patchwork.freedesktop.org/series/11667/
State : failure

== Summary ==

Series 11667v1 drm/i915/dp: add lane_count check in intel_dp_check_link_status
http://patchwork.freedesktop.org/api/1.0/series/11667/revisions/1/mbox/

Test kms_cursor_legacy:
        Subgroup basic-cursor-vs-flip-legacy:
                pass       -> FAIL       (fi-bsw-n3050)
Test kms_pipe_crc_basic:
        Subgroup suspend-read-crc-pipe-a:
                incomplete -> PASS       (fi-hsw-4770k)

fi-bdw-5557u     total:252  pass:235  dwarn:0   dfail:0   fail:2   skip:15 
fi-bsw-n3050     total:252  pass:204  dwarn:0   dfail:0   fail:2   skip:46 
fi-hsw-4770k     total:252  pass:228  dwarn:0   dfail:0   fail:2   skip:22 
fi-hsw-4770r     total:252  pass:224  dwarn:0   dfail:0   fail:2   skip:26 
fi-ivb-3520m     total:252  pass:220  dwarn:0   dfail:0   fail:1   skip:31 
fi-skl-6260u     total:252  pass:236  dwarn:0   dfail:0   fail:2   skip:14 
fi-skl-6700k     total:252  pass:222  dwarn:0   dfail:0   fail:2   skip:28 
fi-snb-2520m     total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 
fi-snb-2600      total:252  pass:207  dwarn:0   dfail:0   fail:2   skip:43 

Results at /archive/results/CI_IGT_test/Patchwork_2441/

9dc3273e7948e9b363ca56d4a86c75ded7d4532a drm-intel-nightly: 2016y-08m-27d-08h-44m-42s UTC integration manifest
0b4c8e1 drm/i915/dp: add lane_count check in intel_dp_check_link_status

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

Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Mika Kahola]

On Sat, 2016-08-27 at 14:33 +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.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index a3c7dd8..0dbb672 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp
> *intel_dp)
>  	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>  		return;
>  
> +	if (!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))) {

Should we place this check as part drm_dp_helper()'s
drm_dp_channel_eq_ok() routine as this may happen with other than our
i915 driver as well?

-- 
Mika Kahola - Intel OTC

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

Re: [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Ville Syrjälä]

On Sat, Aug 27, 2016 at 02:33:25PM +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.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a3c7dd8..0dbb672 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>  	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>  		return;
>  
> +	if (!intel_dp->lane_count)
> +		return;

This pretty much amounts to the same thing that I did with 'active_streams' in 
my series [1]. The problem is that we need to sync up the state on readout to
make it really work. Daniel wasn't too happy with my .sync_state() hook, so
maybe we need something fancier.

[1] https://patchwork.freedesktop.org/series/10354/

> +
>  	/* 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
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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/dp: add lane_count check in intel_dp_check_link_status

[Ville Syrjälä]

On Tue, Sep 06, 2016 at 05:43:44PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 27, 2016 at 02:33:25PM +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.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index a3c7dd8..0dbb672 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3927,6 +3927,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> >  	if (!to_intel_crtc(intel_encoder->base.crtc)->active)
> >  		return;
> >  
> > +	if (!intel_dp->lane_count)
> > +		return;
> 
> This pretty much amounts to the same thing that I did with 'active_streams' in 
> my series [1]. The problem is that we need to sync up the state on readout to
> make it really work. Daniel wasn't too happy with my .sync_state() hook, so
> maybe we need something fancier.
> 
> [1] https://patchwork.freedesktop.org/series/10354/

So, looking at some recent logs I see we may hit this WARN spew a *lot*.
So we probably want this patch as a temporary measure. Maybe with
WARN_ONCE() + a comment, eg.

 /*
  * FIXME need to synchronize this sort of
  * stuff properly with hardware readout.
  */

?

> 
> > +
> >  	/* 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
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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/dp: add lane_count check in intel_dp_check_link_status

[Jani Nikula]

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

-- 
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] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Ville Syrjälä]

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

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

[PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Matthew Auld]

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;
+
 	/* 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

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