On Mon, 10 Aug 2015, Jani Nikula <[email protected]> wrote: > On Thu, 06 Aug 2015, Mika Kuoppala <[email protected]> wrote: >> If we encounter frequent problems with dp aux channel >> communications, we end up spamming the dmesg with the >> exact similar trace and status. >> >> Inject a new backtrace only if we have new information >> to share as otherwise we flush out all other important >> stuff. >> >> Signed-off-by: Mika Kuoppala <[email protected]> >> --- >> drivers/gpu/drm/i915/intel_dp.c | 11 +++++++++-- >> 1 file changed, 9 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c >> b/drivers/gpu/drm/i915/intel_dp.c >> index df7e2cf..6b2f7af 100644 >> --- a/drivers/gpu/drm/i915/intel_dp.c >> +++ b/drivers/gpu/drm/i915/intel_dp.c >> @@ -849,8 +849,15 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, >> } >> >> if (try == 3) { >> - WARN(1, "dp_aux_ch not started status 0x%08x\n", >> - I915_READ(ch_ctl)); >> + static u32 last_status = -1; >> + const u32 status = I915_READ(ch_ctl); >> + >> + if (status != last_status) { >> + WARN(1, "dp_aux_ch not started status 0x%08x\n", >> + status); >> + last_status = status; >> + } >> + > > But now you'll also skip the logging even if there's been a day and a > million successful transfers since the last error... I understand your > concern, but if you feel you must do something like this, please at > least reset last_status on success.
Hmh, I see now that this has already been merged... :( > > BR, > Jani. > > >> ret = -EBUSY; >> goto out; >> } >> -- >> 2.1.4 >> >> _______________________________________________ >> Intel-gfx mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
