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 <pauld...@gmail.com>
>>To: Bin Liu <b-...@ti.com>
>>CC: Felipe Balbi <felipe.ba...@linux.intel.com>
>>
>>Hi,
>>
>>Bin Liu <b-...@ti.com> writes:
>>>>Bin Liu <b-...@ti.com> 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.
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 :)
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
--
Best Regards,
Tushar R Nimkar
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of Code Aurora Forum, hosted by The Linux Foundation
--
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
