| Message ID | 1438868938-3883-1-git-send-email-mika.kuoppala@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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 '*'
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
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; }
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(-)