On 09/21/2013 04:30 AM, Dan Williams wrote:
On Thu, Sep 19, 2013 at 10:24 PM, Pratyush Anand <pratyush.anand@xxxxxx> wrote:
On Fri, Sep 20, 2013 at 05:37:50AM +0800, Sarah Sharp wrote:
On Fri, Sep 13, 2013 at 03:50:48PM +0530, Pratyush Anand wrote:
On Fri, Sep 13, 2013 at 3:40 PM, Xenia Ragiadakou <burzalodowa@xxxxxxxxx>wrote:
Nope :). There is still Kumar 's patch that keeps the wrappers, so it can
be applied instead of mine. But you did not tell me which tool you use
currently to log the mmio operations? it is useful to know.
Sorry, I did not use any standard tool, rather I made local changes in
dwc3_readl and dwc3_writel to log all dwc3 specific read/write
operations into a static array, which was dumped to a text file using
an ARM debugger (trace32) for further analysis.
Would it be helpful to add a trace event for xHCI register reads and
writes (but not a debug statement)? That way you wouldn't have to
change or recompile the kernel at all, but you could use the trace
events infrastructure to enable xHCI register read/write debugging. We
wouldn't flood log files with register reads and writes, but a trace
event makes sense.
I have not used tracepoints. So to understand, looked into
Documentation/trace/tracepoints.txt: "When a tracepoint is "on", the
function you provide is called each time the tracepoint is executed."
So, do you mean to insert tracepoint in xhci_readl/writel? For sure it
would be helpful, but...
Trace ON will be needed only in very special (and a few) case, so
would it be fine to insert a tiny time penalty in readl/writel
routine when trace is off? Not Sure...
It's just a series of nops when tracing is off, so the penalty is
negligible and is already used in hotter paths in the kernel.
Document says "When a tracepoint is "off" it has no effect, except for
adding a tiny time penalty (checking a condition for a branch)"
If anything the "penalty" of xhci_dbg_trace might be something to look
at later on since we take what looks like a 1% object size hit.
--
Dan
Hi Dan,
What do you mean by saying "1% object size hit"? Do you mean 1% increase
in xhci footprint?
Although, I wrote the patches that add traces for xhci debugging
statements, there are some
things that bother me. One is that their functionality can be replicated
in many cases using the dynamic debugging interface, which does not add
any extra overhead, and the other is that xhci_dbg_trace hides the calls
to xhci_dbg(), which restricts the control over the dynamic debug
statements (i.e when someone enables the debug statements of a function
by writing to dynamic_debug/control file in debugfs, and the calls to
dev_dbg() are hidden by calls to xhci_dbg_trace, those debug statements
won't be enabled).
ksenia
--
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
