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
