[Intel-gfx] [PATCH 14/16] drm/i915: Add watermark tracepoints

Ville Syrjälä ville.syrjala at linux.intel.com
Tue Oct 15 12:11:49 CEST 2013

On Tue, Oct 15, 2013 at 10:43:31AM +0200, Daniel Vetter wrote:
> On Fri, Oct 11, 2013 at 04:40:24PM -0300, Paulo Zanoni wrote:
> > 2013/10/9  <ville.syrjala at linux.intel.com>:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > >
> > > We may want to know what kind of watermarks got computed and programmed
> > > into the hardware. Using tracepoints is much leaner than debug prints.
> > >
> > > Also add trace call for the watermark state we read out of the
> > > hardware during init, though I;m not sure there's any way to see that
> > > trace as the events aren't available until the module is loaded.
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > I never worked with these things before, but on a quick look it all sounds sane.
> > 
> > Acked-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> I'm not sold on tracepoints being the right tool here. DRM_DEBUG_KMS
> probably isn't it, since that would needlessly spam dmesg since it's way
> too coarse. But the kernel has this neat dynamic debug subsystem, which
> has the upshot that it's all nicely inline with the other modeset debug
> noise in dmesg.

I need to trace the watermark updates in relation to plane updates and
vblanks. Tracepoints seem like a good tool to me, though it does make
it a bit less useful for bug reports and such. I'm just worried that
regular printks add too much overhead to be all that useful for such
timing sensitive work with potentially quite a bit of trace data.

Ville Syrjälä
Intel OTC

More information about the Intel-gfx mailing list