Hi, 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? -- balbi
Attachment:
signature.asc
Description: PGP signature
