drm/i915: Spam less on dp aux send/receive problems
diff mbox

Message ID 1438868938-3883-1-git-send-email-mika.kuoppala@intel.com
State New
Headers show

Commit Message

Mika Kuoppala Aug. 6, 2015, 1:48 p.m. UTC
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@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

Comments

Jani Nikula Aug. 10, 2015, 8:19 a.m. UTC | #1
On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuoppala@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.kuoppala@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 Aug. 10, 2015, 11:01 a.m. UTC | #2
On Mon, 10 Aug 2015, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuoppala@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.kuoppala@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.

Hmh, I see now that this has already been merged... :(


>
> 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
Daniel Vetter Aug. 11, 2015, 9:59 a.m. UTC | #3
On Mon, Aug 10, 2015 at 02:01:56PM +0300, Jani Nikula wrote:
> On Mon, 10 Aug 2015, Jani Nikula <jani.nikula@linux.intel.com> wrote:
> > On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuoppala@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.kuoppala@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.
> 
> Hmh, I see now that this has already been merged... :(

Well I like the idea, Mika please supply a fixup patch.
-Daniel

> 
> 
> >
> > 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
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Shuang He Aug. 12, 2015, 5:38 p.m. UTC | #4
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 7106
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
ILK                                  302/302              302/302
SNB                                  315/315              315/315
IVB                                  336/336              336/336
BYT                 -1              283/283              282/283
HSW                                  378/378              378/378
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
*BYT  igt@gem_partial_pwrite_pread@reads-uncached      PASS(1)      FAIL(1)
Note: You need to pay more attention to line start with '*'
Mika Kuoppala Aug. 13, 2015, 10:29 a.m. UTC | #5
Daniel Vetter <daniel@ffwll.ch> writes:

> On Mon, Aug 10, 2015 at 02:01:56PM +0300, Jani Nikula wrote:
>> On Mon, 10 Aug 2015, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>> > On Thu, 06 Aug 2015, Mika Kuoppala <mika.kuoppala@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.kuoppala@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.
>> 
>> 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@lists.freedesktop.org
>> >> 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@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Patch
diff mbox

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;
+		}
+
 		ret = -EBUSY;
 		goto out;
 	}