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@xxxxxxxxxxxxxxx> > Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx> > --- > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx