All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Joe Konno <joe.konno@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [RFC 0/3] drm/i915: expose fifo pipe underrun counts
Date: Tue, 26 Jan 2016 21:51:20 +0100	[thread overview]
Message-ID: <20160126205120.GG11240@phenom.ffwll.local> (raw)
In-Reply-To: <1453837017-23209-1-git-send-email-joe.konno@linux.intel.com>

On Tue, Jan 26, 2016 at 11:36:54AM -0800, Joe Konno wrote:
> From: Joe Konno <joe.konno@intel.com>
> 
> In tracking down a watermark bug, I discovered the pch and cpu underrun
> interrupt handlers would disable themselves after initial reports to prevent an
> interrupt/dmesg storm. Storms are bad, but underrun interrupt handling should
> not cease. For my case, I need to be able to count pch and cpu underruns for
> each pipe or transcoder. Displaying this information in the 'i915_display_info'
> node seemed the best course of action.
> 
> In order to do this, however, I had to revisit some long-standing behaviors in
> the underrun interrupt handlers. One problem became three. Thanks in advance
> for your review and feedback.
> 
> Requesting comment on the following solutions I came up with (corresponding to
> each patch in the series):
> 
>   1. provide simple 'getter' mechanisms for pch and cpu underrun reporting
>      ("is it enabled?")-- and base dmesg output on the answer to that question;
> 
>   2. don't allow the interrupt handlers to disable or filter themselves (and
>      prevent accurate counting); and finally
> 
>   3. atomically-incremented pch and cpu underrun counters, with those counters
>      displayed in debugfs i915_display_info per-pipe, per-transcoder
> 
> For: https://bugs.freedesktop.org/show_bug.cgi?id=93865

It's more complicated than this, replied with the technicalities to patch
2. But what I've forgotten to ask: What do you want to use this for? We
make sure that after a full modeset underrun reporting state is restored,
so you can retest for a given bug essentially forever, with no need to
reboot.

And we've also become a lot better at fixing the existing underruns, so
nowadays fifo reporting won't be disable right away even before you
managed to display the very first frame.
-Daniel

> 
> 
> Joe Konno (3):
>   drm/i915: get cpu, pch underrun reporting state
>   drm/i915: do not disable handler after underrun
>   drm/i915: add underrun counts to i915_display_info
> 
>  drivers/gpu/drm/i915/i915_debugfs.c        |  6 ++-
>  drivers/gpu/drm/i915/intel_drv.h           |  4 ++
>  drivers/gpu/drm/i915/intel_fifo_underrun.c | 78 ++++++++++++++++++++++++------
>  3 files changed, 71 insertions(+), 17 deletions(-)
> 
> -- 
> 2.6.4
> 
> _______________________________________________
> 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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2016-01-26 20:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-26 19:36 [RFC 0/3] drm/i915: expose fifo pipe underrun counts Joe Konno
2016-01-26 19:36 ` [RFC 1/3] drm/i915: get cpu, pch underrun reporting state Joe Konno
2016-01-26 19:36 ` [RFC 2/3] drm/i915: do not disable handler after underrun Joe Konno
2016-01-26 20:49   ` Daniel Vetter
2016-01-26 19:36 ` [RFC 3/3] drm/i915: add underrun counts to i915_display_info Joe Konno
2016-01-26 20:51 ` Daniel Vetter [this message]
2016-01-26 21:05   ` [RFC 0/3] drm/i915: expose fifo pipe underrun counts Joe Konno
2016-01-27  8:29     ` Daniel Vetter
2016-01-28  7:13 ` ✗ Fi.CI.BAT: failure for " Patchwork
2016-01-28 15:09 ` ✓ Fi.CI.BAT: success " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160126205120.GG11240@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=joe.konno@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.