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.syrj...@linux.intel.com>: > > > From: Ville Syrjälä <ville.syrj...@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.syrj...@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.zan...@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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
