Re: [PATCH] drm/i915: Spam less on dp aux send/receive problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Daniel Vetter <daniel@xxxxxxxx> writes:

> On Mon, Aug 10, 2015 at 02:01:56PM +0300, Jani Nikula wrote:
>> On Mon, 10 Aug 2015, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>> > On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> 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.kuoppala@xxxxxxxxx>
>> >> ---
>> >>  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... :(
>
> Well I like the idea, Mika please supply a fixup patch.

I have a fixup to clear the last status on success.

And I also patch which get rids of the trickery
and then just WARN_ON_ONCE if try == 3, suggested
by Jani.

As this was just in a way of skl debugging by flooding
logs, both approaches are fine with. What is the
preferred approach for the display devs?

-Mika


> -Daniel
>
>> 
>> 
>> >
>> > BR,
>> > Jani.
>> >
>> >
>> >>  		ret = -EBUSY;
>> >>  		goto out;
>> >>  	}
>> >> -- 
>> >> 2.1.4
>> >>
>> >> _______________________________________________
>> >> Intel-gfx mailing list
>> >> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
>> >> 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
>> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux