Re: howto debug xhci driver?

2018-04-23 Thread Bin Liu 
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 <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.

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: howto debug xhci driver?

2018-04-23 Thread Tushar Nimkar 

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

Re: howto debug xhci driver?

2018-04-23 Thread Bin Liu 
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.

> with dwc3 3.00a

Do you mean you only see the problem in super-speed but not high-speed
with 3.00a?

> 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?

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

Re: howto debug xhci driver?

2018-04-22 Thread Tushar Nimkar 

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 
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 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

Re: howto debug xhci driver?

2018-04-20 Thread Bin Liu 
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 :(

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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: howto debug xhci driver?

2018-03-20 Thread Paul Zimmerman 

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.

--
Paul
--
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

Re: howto debug xhci driver?

2018-03-20 Thread Bin Liu 
On Tue, Mar 20, 2018 at 08:32:19AM -0500, Bin Liu wrote:
> On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Bin Liu  writes:
> > > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote:
> > >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote:
> > >> > 
> > >> > Hi,
> > >> > 
> > >> > Bin Liu  writes:
> > >> > > I am relatively new to xhci and its driver. I am trying to get a xhci
> > >> > > driver runtime log to understand how it handles usb transactions, 
> > >> > > but I
> > >> > > don't get much information with dynamic debug (module xhci_hcd) or
> > >> > > enabling xhci trace events. Is there any other methods you guys use 
> > >> > > to
> > >> > > debug xhci driver?
> > >> > 
> > >> > tracepoints, the best thing since sliced bread ;-)
> > >> 
> > >> I know, but I didn't get any trace log in bulk IN transfers :(
> > >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I
> > >> see you added more since v4.11. I will try to move to the latest kernel.
> > >> 
> > >> > 
> > >> > > 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...

Reproduced the issue with the sourcesink+hid gadget, which adds an
interrupt ep on the bus, so this appears to be bandwidth scheduling
problem...

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

Re: howto debug xhci driver?

2018-03-20 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
>> Bin Liu  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?

Right, your HW folks should have a pointer. Dave K may be a good
starting contact ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: howto debug xhci driver?

2018-03-20 Thread Bin Liu 
On Tue, Mar 20, 2018 at 03:34:16PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  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?

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

Re: howto debug xhci driver?

2018-03-20 Thread Felipe Balbi 

Hi,

Bin Liu  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


signature.asc
Description: PGP signature

Re: howto debug xhci driver?

2018-03-20 Thread Bin Liu 
On Tue, Mar 20, 2018 at 09:14:12AM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote:
> >> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote:
> >> > 
> >> > Hi,
> >> > 
> >> > Bin Liu  writes:
> >> > > I am relatively new to xhci and its driver. I am trying to get a xhci
> >> > > driver runtime log to understand how it handles usb transactions, but I
> >> > > don't get much information with dynamic debug (module xhci_hcd) or
> >> > > enabling xhci trace events. Is there any other methods you guys use to
> >> > > debug xhci driver?
> >> > 
> >> > tracepoints, the best thing since sliced bread ;-)
> >> 
> >> I know, but I didn't get any trace log in bulk IN transfers :(
> >> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I
> >> see you added more since v4.11. I will try to move to the latest kernel.
> >> 
> >> > 
> >> > > 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...

> 
> >> > tracepoints, please :-)
> >
> > I will get tracepoints for cases w/ and w/o a hub.

Both tracepoints logs are the same, only a few lines - enqueue,
dequeue...

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

Re: howto debug xhci driver?

2018-03-20 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
> On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote:
>> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote:
>> > 
>> > Hi,
>> > 
>> > Bin Liu  writes:
>> > > I am relatively new to xhci and its driver. I am trying to get a xhci
>> > > driver runtime log to understand how it handles usb transactions, but I
>> > > don't get much information with dynamic debug (module xhci_hcd) or
>> > > enabling xhci trace events. Is there any other methods you guys use to
>> > > debug xhci driver?
>> > 
>> > tracepoints, the best thing since sliced bread ;-)
>> 
>> I know, but I didn't get any trace log in bulk IN transfers :(
>> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I
>> see you added more since v4.11. I will try to move to the latest kernel.
>> 
>> > 
>> > > 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.

>> > tracepoints, please :-)
>
> I will get tracepoints for cases w/ and w/o a hub.
>
> Regards,
> -Bin.

-- 
balbi


signature.asc
Description: PGP signature

Re: howto debug xhci driver?

2018-03-19 Thread Bin Liu 
On Mon, Mar 05, 2018 at 01:21:42PM -0600, Bin Liu wrote:
> On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Bin Liu  writes:
> > > I am relatively new to xhci and its driver. I am trying to get a xhci
> > > driver runtime log to understand how it handles usb transactions, but I
> > > don't get much information with dynamic debug (module xhci_hcd) or
> > > enabling xhci trace events. Is there any other methods you guys use to
> > > debug xhci driver?
> > 
> > tracepoints, the best thing since sliced bread ;-)
> 
> I know, but I didn't get any trace log in bulk IN transfers :(
> It turns out - I was on v4.9, which doesn't have much tracepoints. Now I
> see you added more since v4.11. I will try to move to the latest kernel.
> 
> > 
> > > 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.

> > tracepoints, please :-)

I will get tracepoints for cases w/ and w/o a hub.

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

Re: howto debug xhci driver?

2018-03-05 Thread Bin Liu 
On Mon, Mar 05, 2018 at 10:16:49AM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > I am relatively new to xhci and its driver. I am trying to get a xhci
> > driver runtime log to understand how it handles usb transactions, but I
> > don't get much information with dynamic debug (module xhci_hcd) or
> > enabling xhci trace events. Is there any other methods you guys use to
> > debug xhci driver?
> 
> tracepoints, the best thing since sliced bread ;-)

I know, but I didn't get any trace log in bulk IN transfers :(
It turns out - I was on v4.9, which doesn't have much tracepoints. Now I
see you added more since v4.11. I will try to move to the latest kernel.

> 
> > 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?
> 
> tracepoints, please :-)

I will :)
I checked the xhci spec, but didn't find any info on what controls
xhci's behavor on IN-NAK...

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

Re: howto debug xhci driver?

2018-03-05 Thread Felipe Balbi 

Hi,

Bin Liu  writes:
> I am relatively new to xhci and its driver. I am trying to get a xhci
> driver runtime log to understand how it handles usb transactions, but I
> don't get much information with dynamic debug (module xhci_hcd) or
> enabling xhci trace events. Is there any other methods you guys use to
> debug xhci driver?

tracepoints, the best thing since sliced bread ;-)

> 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?

> Any one has a clue on what causes xhci to stop sending IN tokens after
> the device NAK'd 4 times?

tracepoints, please :-)

-- 
balbi
--
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

howto debug xhci driver?

2018-03-02 Thread Bin Liu 
Hi,

I am relatively new to xhci and its driver. I am trying to get a xhci
driver runtime log to understand how it handles usb transactions, but I
don't get much information with dynamic debug (module xhci_hcd) or
enabling xhci trace events. Is there any other methods you guys use to
debug xhci driver?

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.

Any one has a clue on what causes xhci to stop sending IN tokens after
the device NAK'd 4 times?

Thanks,
-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