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 ? I guess with that we would have a pretty neat setup where we can trace TRB lifetime, all register accesses and events. -- balbi
Attachment:
signature.asc
Description: Digital signature
