On Mon, Apr 23, 2018 at 11:14:55AM +0530, Tushar Nimkar wrote: > On 2018-04-21 00:03, Bin Liu wrote: > >Hi, > > > >On Tue, Mar 20, 2018 at 02:28:00PM -0700, Paul Zimmerman wrote: > >>Forgot to CC linux-usb. > >> > >> > >>-------- Forwarded Message -------- > >>Subject: Re: howto debug xhci driver? > >>Date: Tue, 20 Mar 2018 13:56:21 -0700 > >>From: Paul Zimmerman <pauldzim@xxxxxxxxx> > >>To: Bin Liu <b-liu@xxxxxx> > >>CC: Felipe Balbi <felipe.balbi@xxxxxxxxxxxxxxx> > >> > >>Hi, > >> > >>Bin Liu <b-liu@xxxxxx> writes: > >>>>Bin Liu <b-liu@xxxxxx> writes: > >>>>>>>>>>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... > >>>> > >>>>is this AM4 or AM5? Perhaps go after Synopsys' known errata list? > >>> > >>>I see the issue on both AM4 & AM5. I don't have access to the > >>>errata list, I guess I should talk to TI internal for the list? > >> > >>I have a hazy recollection of something like this being a "feature" of > >>the Synopsys core, to cut down on the excessive number of IN-NAK > >>transactions you can sometimes get on the USB bus. So yep, you > >>should talk to your Synopsys guy about this. > > > >Thanks for the information. We have been talking to Synopsis for this > >issue, the progress is slow, one of the reasons is that the DWC3 > >version > >is very old :( > Bin, What is the version no? I have seen similar thing but on USB3.0 On multiple versions: from 2.02a to 2.60a. > with dwc3 3.00a Do you mean you only see the problem in super-speed but not high-speed with 3.00a? > May I know how you confirmed/debug missing IN-ACK? Using bus protocol analyzer to capture bus traces. However my issue is not about missing IN-ACK, but IN-NAK - the host stops sending IN tokens too early if the device NAK'd previous IN packets. Please confirm you mean IN-NAK instead in your case? Regards, -Bin. -- 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
