On Mon, Apr 23, 2018 at 07:21:12PM +0530, Tushar Nimkar wrote: > Hi, > > On 2018-04-23 18:58, Bin Liu wrote: > >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. > suggest you to check errata list if not. Yeah, stuck at here right now - too slow to get a copy of the errata :( > > > >>with dwc3 3.00a > > > >Do you mean you only see the problem in super-speed but not high-speed > >with 3.00a? > yes so far.. > > > >>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? > it is IN-ACK, ss device send ERDY there should be IN-ACK saying NumP > > 0 from host :) Sounds like we face two different issues then :) 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
