Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 7/7] drm/i915: Add pipe update trace points
Date: Fri, 13 Dec 2013 10:47:11 +0200	[thread overview]
Message-ID: <20131213084711.GL10036@intel.com> (raw)
In-Reply-To: <20131212130816.6e45ab18@jbarnes-desktop>

On Thu, Dec 12, 2013 at 01:08:16PM -0800, Jesse Barnes wrote:
> On Thu, 17 Oct 2013 22:53:19 +0300
> ville.syrjala@linux.intel.com wrote:
> 
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > Add trace points for observing the atomic pipe update mechanism.
> > 
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_trace.h   | 77 +++++++++++++++++++++++++++++++++++++
> >  drivers/gpu/drm/i915/intel_sprite.c |  6 +++
> >  2 files changed, 83 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> > index 6e580c9..9ffb232 100644
> > --- a/drivers/gpu/drm/i915/i915_trace.h
> > +++ b/drivers/gpu/drm/i915/i915_trace.h
> > @@ -7,6 +7,7 @@
> >  
> >  #include <drm/drmP.h>
> >  #include "i915_drv.h"
> > +#include "intel_drv.h"
> >  #include "intel_ringbuffer.h"
> >  
> >  #undef TRACE_SYSTEM
> > @@ -14,6 +15,82 @@
> >  #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
> >  #define TRACE_INCLUDE_FILE i915_trace
> >  
> > +/* pipe updates */
> > +
> > +TRACE_EVENT(i915_pipe_update_start,
> > +	    TP_PROTO(struct drm_crtc *crtc, u32 min, u32 max),
> > +	    TP_ARGS(crtc, min, max),
> > +
> > +	    TP_STRUCT__entry(
> > +			     __field(enum pipe, pipe)
> > +			     __field(u32, frame)
> > +			     __field(u32, scanline)
> > +			     __field(u32, min)
> > +			     __field(u32, max)
> > +			     ),
> > +
> > +	    TP_fast_assign(
> > +			   __entry->pipe = to_intel_crtc(crtc)->pipe;
> > +			   __entry->frame = crtc->dev->driver->get_vblank_counter(crtc->dev,
> > +										  to_intel_crtc(crtc)->pipe);
> > +			   __entry->scanline = i915_get_crtc_scanline(crtc);
> > +			   __entry->min = min;
> > +			   __entry->max = max;
> > +			   ),
> > +
> > +	    TP_printk("pipe %c, frame=%u, scanline=%u, min=%u, max=%u",
> > +		      pipe_name(__entry->pipe), __entry->frame,
> > +		       __entry->scanline, __entry->min, __entry->max)
> > +);
> > +
> > +TRACE_EVENT(i915_pipe_update_vblank_evaded,
> > +	    TP_PROTO(struct drm_crtc *crtc, u32 min, u32 max),
> > +	    TP_ARGS(crtc, min, max),
> > +
> > +	    TP_STRUCT__entry(
> > +			     __field(enum pipe, pipe)
> > +			     __field(u32, frame)
> > +			     __field(u32, scanline)
> > +			     __field(u32, min)
> > +			     __field(u32, max)
> > +			     ),
> > +
> > +	    TP_fast_assign(
> > +			   __entry->pipe = to_intel_crtc(crtc)->pipe;
> > +			   __entry->frame = crtc->dev->driver->get_vblank_counter(crtc->dev,
> > +										  to_intel_crtc(crtc)->pipe);
> > +			   __entry->scanline = i915_get_crtc_scanline(crtc);
> > +			   __entry->min = min;
> > +			   __entry->max = max;
> > +			   ),
> > +
> > +	    TP_printk("pipe %c, frame=%u, scanline=%u, min=%u, max=%u",
> > +		      pipe_name(__entry->pipe), __entry->frame,
> > +		       __entry->scanline, __entry->min, __entry->max)
> > +);
> > +
> > +TRACE_EVENT(i915_pipe_update_end,
> > +	    TP_PROTO(struct drm_crtc *crtc),
> > +	    TP_ARGS(crtc),
> > +
> > +	    TP_STRUCT__entry(
> > +			     __field(enum pipe, pipe)
> > +			     __field(u32, frame)
> > +			     __field(u32, scanline)
> > +			     ),
> > +
> > +	    TP_fast_assign(
> > +			   __entry->pipe = to_intel_crtc(crtc)->pipe;
> > +			   __entry->frame = crtc->dev->driver->get_vblank_counter(crtc->dev,
> > +										  to_intel_crtc(crtc)->pipe);
> > +			   __entry->scanline = i915_get_crtc_scanline(crtc);
> > +			   ),
> > +
> > +	    TP_printk("pipe %c, frame=%u, scanline=%u",
> > +		      pipe_name(__entry->pipe), __entry->frame,
> > +		      __entry->scanline)
> > +);
> > +
> >  /* object tracking */
> >  
> >  TRACE_EVENT(i915_gem_object_create,
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
> > index f871b8f..874ffc1 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -63,6 +63,8 @@ static void intel_pipe_update_start(struct drm_crtc *crtc)
> >  
> >  	local_irq_disable();
> >  
> > +	trace_i915_pipe_update_start(crtc, min, max);
> > +
> >  	intel_crtc->vbl_received = false;
> >  	scanline = i915_get_crtc_scanline(crtc);
> >  
> > @@ -78,10 +80,14 @@ static void intel_pipe_update_start(struct drm_crtc *crtc)
> >  	}
> >  
> >  	drm_vblank_put(dev, pipe);
> > +
> > +	trace_i915_pipe_update_vblank_evaded(crtc, min, max);
> >  }
> >  
> >  static void intel_pipe_update_end(struct drm_crtc *crtc)
> >  {
> > +	trace_i915_pipe_update_end(crtc);
> > +
> >  	local_irq_enable();
> >  }
> >  
> 
> Not sure about the "vblank_evaded" one.  Seems like you'd have enough
> info from the start/end to figure out if you missed, since you'd have
> the time and vblank seqno, right?   But that's really no biggie.

The evaded tracepoint is quite important since it allows us to verify
that the evaded->end sequence really took place during one frame.
start->end doesn't really tell us much because when the vblank gets
evaded those two tracepoints land on alternate frames.

> 
> It does make me think we should start documenting these events though...
> 
> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> 
> -- 
> Jesse Barnes, Intel Open Source Technology Center

-- 
Ville Syrjälä
Intel OTC

      reply	other threads:[~2013-12-13  8:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17 19:53 [PATCH 0/7] drm/i915: Atomic sprites ville.syrjala
2013-10-17 19:53 ` [PATCH 1/7] drm/i915: Don't disable primary when color keying is used ville.syrjala
2013-12-12 20:56   ` Jesse Barnes
2013-12-12 20:58     ` Daniel Vetter
2013-12-13  8:41       ` Ville Syrjälä
2013-10-17 19:53 ` [PATCH 2/7] drm/i915: Fix non-scaled sprites for ILK ville.syrjala
2013-10-17 20:56   ` Chris Wilson
2013-10-18  7:35     ` Ville Syrjälä
2013-10-17 19:53 ` [PATCH 3/7] drm/i915: Add i915_get_crtc_scanline() ville.syrjala
2013-12-12 20:59   ` Jesse Barnes
2013-10-17 19:53 ` [PATCH 4/7] drm/i915: Shuffle sprite register writes into a tighter group ville.syrjala
2013-12-12 21:00   ` Jesse Barnes
2013-10-17 19:53 ` [PATCH 5/7] drm/i915: Make sprite updates atomic ville.syrjala
2013-12-12 21:04   ` Jesse Barnes
2013-12-12 21:09   ` Jesse Barnes
2013-10-17 19:53 ` [PATCH 6/7] drm/i915: Perform primary enable/disable atomically with sprite updates ville.syrjala
2013-12-12 21:06   ` Jesse Barnes
2013-10-17 19:53 ` [PATCH 7/7] drm/i915: Add pipe update trace points ville.syrjala
2013-12-12 21:08   ` Jesse Barnes
2013-12-13  8:47     ` Ville Syrjälä [this message]

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=20131213084711.GL10036@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jbarnes@virtuousgeek.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox