Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
On Thu, 20 Oct 2016, Matthew Auldwrote: > 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ä > Cc: Mika Kahola > Signed-off-by: Matthew Auld > --- > 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: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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ä> Cc: Mika Kahola > Signed-off-by: Matthew Auld > --- > 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ä > + > /* 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
[Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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äCc: Mika Kahola Signed-off-by: Matthew Auld --- 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
Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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> > Signed-off-by: Matthew Auld > > --- > > 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: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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> Signed-off-by: Matthew Auld > --- > 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: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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> Signed-off-by: Matthew Auld > --- > 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
[Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status
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 NikulaSigned-off-by: Matthew Auld --- 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