On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuopp...@linux.intel.com> 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 <mika.kuopp...@intel.com>
> ---
> 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.
BR,
Jani.
> ret = -EBUSY;
> goto out;
> }
> --
> 2.1.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
