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

[Vanshidhar Konda]

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?

>> >
>> >>
>> >> >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