On Tue, Mar 20, 2018 at 08:32:19AM -0500, Bin Liu wrote: > On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote: > > > > Hi, > > > > Bin Liu <b-...@ti.com> writes: > > > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote: > > >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote: > > >> > > > >> > Hi, > > >> > > > >> > Bin Liu <b-...@ti.com> writes: > > >> > > I am relatively new to xhci and its driver. I am trying to get a xhci > > >> > > driver runtime log to understand how it handles usb transactions, > > >> > > but I > > >> > > don't get much information with dynamic debug (module xhci_hcd) or > > >> > > enabling xhci trace events. Is there any other methods you guys use > > >> > > to > > >> > > debug xhci driver? > > >> > > > >> > tracepoints, the best thing since sliced bread ;-) > > >> > > >> I know, but I didn't get any trace log in bulk IN transfers :( > > >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I > > >> see you added more since v4.11. I will try to move to the latest kernel. > > >> > > >> > > > >> > > BTY, the issue I am trying to debug is when reading bulk IN data > > >> > > from a > > >> > > USB2.0 device, if the device doesn't have data to transmit and NAKs > > >> > > the > > >> > > IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending > > >> > > further IN tokens until the next SOF, which leaves ~90us gape on the > > >> > > bus. > > >> > > > > >> > > But when reading data from a USB2.0 thumb drive, this issue doesn't > > >> > > happen, even if the device NAKs the IN tokens, xhci still keeps > > >> > > sending > > >> > > IN tokens, which is way more than 4 pairs of IN-NAK transactions. > > >> > > > >> > Thumb drive has Bulk endpoints, what is the other device's transfer > > >> > type? > > >> > > >> It is bulk too. I asked for device descriptors. This is a remote debug > > >> effort for me, I don't have that device... > > >> > > >> > > > >> > > Any one has a clue on what causes xhci to stop sending IN tokens > > >> > > after > > >> > > the device NAK'd 4 times? > > > > > > By accident, I reproduced the issue if addng a hub in the middle... > > > any comments about why a hub changes this xhci behavior is appreciated. > > > > none off the top of my head. Maybe Mathias can suggest something. > > The issue seems to be not related to how many bulk IN-NAK pairs before > host stops sending IN token, but the host stops IN token if 1) the > device ever NAK'd an bulk IN token, and 2) there is about 90~100us left > to the next SOF. Then all the rest of bandwidth is wasted. > > Is it about xhci bandwidth schduling? /me started reading...
Reproduced the issue with the sourcesink+hid gadget, which adds an interrupt ep on the bus, so this appears to be bandwidth scheduling problem... Regards, -Bin. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
