| Message ID | 20190314175844.GA16548@vrkonda-desk.ra.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/i915/display: Reduce log level for DP command signal timeout | expand |
I'll add the Signed Off by line when I re-submit the patch after a review. Thanks, Vanshi 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"); >#undef C > > return status; >-- >2.20.1 > >_______________________________________________ >Intel-gfx mailing list >Intel-gfx@lists.freedesktop.org >https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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. > #undef C > > return status; > -- > 2.20.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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). 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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >-- >Ville Syrjälä >Intel
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 the aux hw should terminate with a proper timeout. I'm tempted to 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@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > >-- > >Ville Syrjälä > >Intel
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? >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@lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> > >> >-- >> >Ville Syrjälä >> >Intel > >-- >Ville Syrjälä >Intel
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@lists.freedesktop.org > >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >> > > >> >-- > >> >Ville Syrjälä > >> >Intel > > > >-- > >Ville Syrjälä > >Intel
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@lists.freedesktop.org >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> > >> >> >-- >> >> >Ville Syrjälä >> >> >Intel >> > >> >-- >> >Ville Syrjälä >> >Intel > >-- >Ville Syrjälä >Intel
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@lists.freedesktop.org > >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >> >> > > >> >> >-- > >> >> >Ville Syrjälä > >> >> >Intel > >> > > >> >-- > >> >Ville Syrjälä > >> >Intel > > > >-- > >Ville Syrjälä > >Intel
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@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
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"); #undef C return status;