From: Kalle Valo <kvalo@qca.qualcomm.com>
To: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
Xenia Ragiadakou <burzalodowa@gmail.com>,
OPW Kernel Interns List <opw-kernel-interns@googlegroups.com>,
<linux-usb@vger.kernel.org>, <linux-wireless@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: Help adding trace events to xHCI
Date: Fri, 12 Jul 2013 07:25:59 +0300 [thread overview]
Message-ID: <87y59c4d60.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <20130711190035.GD5240@xanatos> (Sarah Sharp's message of "Thu, 11 Jul 2013 12:00:35 -0700")
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> My initial list of specific trace points was something like:
>
> 1. xHCI host initialization and shutdown
>
> 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
>
> 3. A few individual xHCI host controller command tracepoints:
> * status only for all completed commands
> * Address Device command status and output
> * Configure Endpoint and Evaluate Context output
> * individual trace points for other xHCI commands
>
> 4. Tracepoints for all USB transfer types:
> * Control TX output (only for non-successful transfers)
> * Bulk TX
> * Interrupt TX
> * Isoc TX
>
> 5. URB cancellation
>
> And probably more. Basically, I want to be able to control what gets
> printed, based on where I think the xHCI bug might be. Does that sound
> reasonable?
Instead of individual trace points for command I would recommend to
consider just pushing the whole command buffer to the trace point and
parse the command in trace-cmd plugin in user space. Kernel code would
be simpler that way.
--
Kalle Valo
next prev parent reply other threads:[~2013-07-12 4:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51DB0257.1010709@gmail.com>
2013-07-11 16:20 ` Help adding trace events to xHCI Sarah Sharp
2013-07-11 17:08 ` Arend van Spriel
2013-07-11 17:08 ` Johannes Berg
2013-07-11 19:00 ` Sarah Sharp
2013-07-12 4:25 ` Kalle Valo [this message]
2013-07-12 16:41 ` Sarah Sharp
2013-07-12 16:55 ` Steven Rostedt
2013-07-15 13:47 ` Jiri Olsa
2013-07-12 17:08 ` Mathieu Desnoyers
2013-07-12 19:35 ` Mark Wielaard
2013-07-12 19:35 ` Mark Wielaard
2013-07-12 19:35 ` Mark Wielaard
2013-07-15 12:55 ` Mathieu Desnoyers
2013-07-12 18:59 ` Kalle Valo
2013-07-26 9:16 ` Johannes Berg
2013-07-11 19:29 ` Steven Rostedt
2013-07-26 9:19 ` Johannes Berg
2013-07-26 12:28 ` Steven Rostedt
2013-07-26 13:06 ` Johannes Berg
2013-07-26 13:17 ` Steven Rostedt
2013-07-26 13:45 ` Johannes Berg
2013-07-26 14:05 ` Steven Rostedt
2013-07-12 4:23 ` Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y59c4d60.fsf@kamboji.qca.qualcomm.com \
--to=kvalo@qca.qualcomm.com \
--cc=burzalodowa@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-usb@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=opw-kernel-interns@googlegroups.com \
--cc=rostedt@goodmis.org \
--cc=sarah.a.sharp@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.