From: "Du, Changbin" <changbin.du@intel.com>
To: Felipe Balbi <balbi@kernel.org>
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
Thread-Topic: [PATCH v4 2/2] usb: dwc3: add debugfs node to dump FIFO/Queue
 available space
Thread-Index: AQHRlK13d4fDYt/zWE+iRtI9QMtm1J+ImJAAgAC0uAD//4IPgIAAh4yw//9+34CAAIfZ8A==
Date: Thu, 14 Apr 2016 11:58:47 +0000
Message-ID: <0C18FE92A7765D4EB9EE5D38D86A563A05D095BA@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>
 <87k2k0ju2y.fsf@intel.com>
In-Reply-To: <87k2k0ju2y.fsf@intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="gb2312"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 2126
Lines: 57

> 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!
> >> > :)
> >>
> >> 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:
> >>
> >> # mount -t debugfs none /sys/kernel/debug
> >> # cd /sys/kernel/debug/tracing
> >> # echo 2048 > buffer_size_kb
> >> # echo 1 > events/dwc3/enable
> >>
> >> (do something to break it)
> >>
> >> # cp trace /mnt/sdcard # or something like that
> >>
> >> 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.
> >>
> >> --
> >> 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
> >      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.
> 
> --
> Balbi

Okay, things need finish step by step. Thank you, Balbi. ( ?b- ?b)?ĥ?

Best Regards,
Du, Changbin