> From: Felipe Balbi [mailto:balbi@xxxxxx] > Sent: Tuesday, August 19, 2014 1:10 PM > > On Tue, Aug 19, 2014 at 08:00:27PM +0000, Paul Zimmerman wrote: > > > From: Felipe Balbi [mailto:balbi@xxxxxx] > > > Sent: Tuesday, August 19, 2014 12:09 PM > > > > > > When we're debugging hard-to-reproduce and time-sensitive > > > use cases, printk() poses too much overhead. That's when > > > the kernel's tracing infrastructure comes into play. > > > > > > This patch implements a few initial tracepoints for the > > > dwc3 driver. More traces can be added as necessary in order > > > to ease the task of debugging dwc3. > > > > > > Signed-off-by: Felipe Balbi <balbi@xxxxxx> > > > --- > > > > > > Hi guys, > > > > > > here's v2 of my dwc3 tracepoints patch. Please have a look and > > > *CAREFULLY* consider if we want to add anything else. > > > > > > Paul, I believe you have much more experience in debugging early > > > HW releases with FPGA models than any of us, so tracing is likely > > > to help you, is there anything you'd want me to add to as a tracepoint ? > > > > What about the "unexpected" interrupt events? It would be nice to see if > > we receive e.g. an EVENT_OVERFLOW interrupt. Especially since you have > > some of those events enabled, but don't have handlers for all of them. > > > > Maybe a single tracepoint for all of the unexpected events? > > Makes sense, I was thinking of a neater way to just pass the event > structure and decode it withing the trace itself. Then we can even > remove all the event-specific traces, would that help ? Yeah, that's sounds even better. > I guess with that we would have a pretty neat setup where we can trace > TRB lifetime, all register accesses and events. Nice. -- Paul -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
