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

[Vanshidhar Konda]

On Fri, Mar 15, 2019 at 03:35:04PM +0200, Ville Syrjälä wrote:
>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.
>

Ok. Let me send a patch for that then. I'll cc you and Imre on that
patch. Thank you!

>>
>> >> >
>> >> >>
>> >> >> >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
>
>-- 
>Ville Syrjälä
>Intel