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 :( However, I just realized that in this case even though DWC3 in host mode doesn't fully utilize the bus bandwidth, it doesn't violate any of the USB Specs, as the Specs don't define flow control for bulk IN transfer. The USB device shouldn't use bulk protocol at the first place if it has bus bandwidth requirements. Isoch probably is a better choice. I will check if there is anything can be done on the USB device side to solve the problem. Thanks all for the help. 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
