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
with dwc3 3.00a
May I know how you confirmed/debug missing IN-ACK?
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
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
