On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote: > On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote: > >On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote: > >> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote: > >> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote: > >> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote: > >> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote: > >> >> >> The log level for timeout after waiting for a signal on the DP aux > >> >> >> channel control register is set to DRM_ERROR. But this is timeout not a > >> >> >> fatal error as the driver is expected to retry the command. Failure > >> >> >> after all retries is already captured as an error. Hence, reducing the > >> >> >> log for a timeout to warning instead of error. > >> >> >> --- > >> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +- > >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> >> >> > >> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > >> >> >> index 47857f96c3b1..f51e8b2ccb17 100644 > >> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c > >> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c > >> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp) > >> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true); > >> >> >> > >> >> >> if (!done) > >> >> >> - DRM_ERROR("dp aux hw did not signal timeout!\n"); > >> >> >> + DRM_WARN("dp aux hw did not signal timeout!\n"); > >> >> > > >> >> >IIRC this indicates the hw is broken. > >> >> > > >> >> Does this indicate an issue with Intel GFX/display device, or the > >> >> display/monitor connected to the DP port? > >> >> > >> >> FYI, this is for FDO #109982 > >> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982). > >> > > >> >There's nothing connected I believe. But in either case I believe > >> > >> >From the two logs for the issue, e-DP1 is the only display connected to > >> the test machine when it generated this error. > >> > >> >the aux hw should terminate with a proper timeout. I'm tempted to > >> > >> If we think that there should be no timeout, would it make more sense to > >> return an error to the caller and having the caller handle the error? > > > >How would it handle the error? > > > >> > >> >blame the typec/tbt stuff here too. > Could it be possible that the addition of typec/tbt to ICL has added > additional latency to the DP register being signaled? Would it make > sense to increase the 10 ms timeout to something larger? Imre just told me the hw timeout was increased to 4ms. So 10ms should still be sufficient I guess. But it wouldn't hurt to at least test longer timeouts a bit to see if the hw ever gets around to signalling the timeout. > > >> > > >> >> > >> >> >From the logs, it seems like this timeout only occurs once. The next try > >> >> succeeds without issues. > >> >> > >> >> >> #undef C > >> >> >> > >> >> >> return status; > >> >> >> -- > >> >> >> 2.20.1 > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Intel-gfx mailing list > >> >> >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >> >> > > >> >> >-- > >> >> >Ville Syrjälä > >> >> >Intel > >> > > >> >-- > >> >Ville Syrjälä > >> >Intel > > > >-- > >Ville Syrjälä > >Intel -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx