On Tue, Oct 15, 2013 at 01:11:49PM +0300, Ville Syrjälä wrote: > 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@xxxxxxxxxxxxxxx>: > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > 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@xxxxxxxxxxxxxxx> > > > > > > I never worked with these things before, but on a quick look it all sounds sane. > > > > > > Acked-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> > > > > 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. Hm, I've thought we'd only dump the wm state once it's computed before we bash it into the hw. That part doesn't really feel timing critical, at least as long as we have the printks disabled by default. Otherwise syslogd will bring the system down ;-) Now I haven't really played around with it yet, but the dynamic printk stuff seemed to fit that bill. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
