[Intel-gfx] [PATCH] drm/i915/display: Reduce log level for DP command signal timeout

[Ville Syrjälä]

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.
> >
> >>
> >> >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 at lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >
> >> >--
> >> >Ville Syrjälä
> >> >Intel
> >
> >-- 
> >Ville Syrjälä
> >Intel

-- 
Ville Syrjälä
Intel