Hi, On Fri, Aug 22, 2014 at 09:26:55PM +0000, Paul Zimmerman wrote: > > diff --git a/drivers/usb/dwc3/debug.c b/drivers/usb/dwc3/debug.c > > new file mode 100644 > > index 0000000..6d01e0c > > --- /dev/null > > +++ b/drivers/usb/dwc3/debug.c > > @@ -0,0 +1,33 @@ > > +/** > > + * debug.c - DesignWare USB3 DRD Controller Debug/Trace Support > > + * > > + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com > > + * > > + * Author: Felipe Balbi <balbi@xxxxxx> > > + * > > + * This program is free software: you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 of > > + * the License as published by the Free Software Foundation. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + */ > > + > > +#include "debug.h" > > + > > +void dwc3_trace(void (*trace)(struct va_format *), > > + const char *fmt, ...) > > Unnecessary line wrap? It looks like this would fit on one line. fixed all three instances > > @@ -726,6 +732,8 @@ static void dwc3_ep0_inspect_setup(struct dwc3 *dwc, > > if (!dwc->gadget_driver) > > goto out; > > > > + trace_dwc3_ctrl_req(ctrl); > > I don't see this function defined anywhere in this patch. Same for some > of the other trace functions. I guess these are automatically defined > by some tracing macro magic? Is there any way to see what the event yup, you got it. If you look at trace.h, it defines all the trace points and on trace.c where we have: #define CREATE_TRACE_POINTS #include "trace.h" that'll cause the creation of all these functions. > will look like short of running the code? These are probably dumb > questions, but I haven't done anything yet with the tracing API, so > I'm pretty clueless about it. Next week I'll send you a sample output with all events enabled :-) > Other than that, I can't think of anything else to be added at this > point. As you say, other trace points can be added later if desired. Right, I wanted to have a way of using those debug registers (GDBG*) for tracing the internal HW blocks but there's no documentation about what those registers mean i.e. how to decode the data returned by them. Other than that... we might want to, at some point, have a more granular tracing of the TRB/usb_request lifetime - right now we're only tracing alloc, queue, dequeue, free - but I guess tracing request accesses alone is already a pretty good deal, as it can help communicating with IP folks and giving them a sequence of events for writing RTL simulation :-) cheers -- balbi
Attachment:
signature.asc
Description: Digital signature
