From: Felipe Balbi <balbi@kernel.org>
To: "Du\, Changbin" <changbin.du@intel.com>
Cc: "gregkh\@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "linux-usb\@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue available space
In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A05D09572@shsmsx102.ccr.corp.intel.com>
References: <1460459419-9487-1-git-send-email-changbin.du@intel.com> <1460459419-9487-3-git-send-email-changbin.du@intel.com> <87shyok47z.fsf@intel.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D09504@shsmsx102.ccr.corp.intel.com> <87mvowjv58.fsf@intel.com> <0C18FE92A7765D4EB9EE5D38D86A563A05D09572@shsmsx102.ccr.corp.intel.com>
User-Agent: Notmuch/0.21+96~g9bbc54b (http://notmuchmail.org) Emacs/25.0.90.3 (x86_64-pc-linux-gnu)
Date: Thu, 14 Apr 2016 14:41:41 +0300
Message-ID: <87k2k0ju2y.fsf@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2930
Lines: 79

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

"Du, Changbin" <changbin.du@intel.com> writes:
>> > At last, comparing with the FIFO/Queue info, I think software transfer
>> > Requests list, TRBs info, EVENTs history are much more useful for
>> debugging
>> > the driver. If you can also add these info to each EP folder, that is =
awesome!
>> > :)
>>=20
>> I'll think about adding these but for the lifetime of requests and trbs
>> and events, etc, we have tracepoints for that. I usually do the
>> following when debugging:
>>=20
>> # mount -t debugfs none /sys/kernel/debug
>> # cd /sys/kernel/debug/tracing
>> # echo 2048 > buffer_size_kb
>> # echo 1 > events/dwc3/enable
>>=20
>> (do something to break it)
>>=20
>> # cp trace /mnt/sdcard # or something like that
>>=20
>> then read the file. You can make it as large or as small as you like
>> (given some constraints, of course ;-) but I've had no issues allocating
>> 128MiB in the past.
>>=20
>> --
>> Balbi
>
> Thanks for the sharing, this is a good approach to capture dynamic
> behaviors. But a dump of current state has below advantages:
> 1. a quick view for the pending transfers. Then we can quickly=20
>      checking the transfer status.
> 2. no side-effect. This is important in some case. We usually
>     encounter some transfer issues but very hard to reproduce
>     it. But we cannot enable trace all the time since performance
>     concern. Then I thought it was so great if I can have a look for
>     the trb status. :)

yeah, okay. We can definitely add "current state" of almost anything,
but if you need history, then debugfs is not the best interface and I'd
point you to tracepoints ;-)

I'll think about how I can add TRB state, seems like we'd need to dump
the entire endpoint ring, and that's 256 TRBs per endpoint :-p Then we
also need to know endpoint's dequeue and enqueue pointer. Oh well, let
me get this first setup of files out of the way, then we can add more
later much more easily.

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJXD4H2AAoJEIaOsuA1yqREp4oQAJ2Er2Pnu/I3TtmdsMe8AwBJ
7Yhh4/3nSBXOaFHjrA8Zpd1BFITo+I1LXq/XQmBUpmxSw4AF+fzx9hIW+cxTHQhe
kn4/86jPqs4BfcR09SWjqS/VFZWJDyl5gcwcfQYww/Bti+89f4j524RjQ2UH91As
3s4j+crptdDM/3+Nqw4atNqBOxE9wpUVqCEmUxT1sqDLugdZSj2NLVZ5Rtp2sDgF
6H+ed4kaQocbgAN3RYu2eYLyCBZtYwqvnUPS39ThpLe3B3S5jV7o4osmUPHm8gk9
P1xSQ4nYL5fmPeNVd/Y3Ou66QbER/VCNeNB/wHIypzjCxNeTtxcs5vl9tTBUeY4H
7f1rewVl2tPVf8zAanD/snvLRaQ7z5RRhiF5i9esRDRRsbQF38FNFp0qfLUnb/sD
wcD46mVC/0+VLYW9RGzowYMkhFSGqyPqYvO0QTele0A1ixVD14sYQ5AzNmWsZM3w
pdhv7306oa1tt8iOMsLFPcILdR4XQhR+iioE7mQeVcPNWHETeRZKebjQN8fzOD2D
AaNkkwbvoG6BH0LeeicNaUDZISq5N3tBsRqmK4PlBFg71+HjjdKy5UGM7eiuCVMK
ZH2zL2loR6KsumqEobNCD+egfcoR7I9FmncRa5FaPRrPfH5CzJqimdAQFAttBIxp
ScdyGrmYo039Q73aFnGF
=H6xv
-----END PGP SIGNATURE-----
--=-=-=--