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@xxxxxxxxxxxxxxxxxxxxx
> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >
> >> >--
> >> >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
