RE: Iso trbs for xhci arrangement
> From: vichy [mailto:vichy@gmail.com]
> Sent: Tuesday, July 22, 2014 9:27 AM
>
> My questions are
> 1. The xhci controller seems not handle the normal TRB for short package.
>as you can see the length of event package for normal package is 0.
>am I correct?
> 2. if above #1 is correct, how xhci controller get the left 0x6f8 data
>in original normal package?
This looks like a hardware bug to me. Which xHCI controller is this?
>>>
>>> Synopsys
>>
>> Ouch ;)
>>
> the controller did fire iso in token to get 0x4fc bytes, above
> marked "", and if xhci controller didn't firing the left in tokens
> to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not
> continuous, right?
I would bet that no data was transferred at all, but the controller
forgot to set the transfer length correctly for the chained normal TRB.
>>>
>>> so you mean the ISO will be sent but the chained normal TRB won't.
>>> that mean the host only get 0x4fc instead of total 0xbf4 Bytes.
>>> Am I right?
>>
>> No, I'm thinking that no data at all was received. That is what the Isoc
>> event TRB shows.
>
> But from isoc event TRB it shows there did get 0x4fc bytes from
> device, since the data length of event trb is not 0.
No. Read the description of the TRB Transfer Length field in section
6.4.2.1 of the xHCI spec. "This field shall reflect the residual number
of bytes not transferred".
Are you seeing an actual problem with this? If not, maybe the xHCI driver
is written in such a way that this does not cause a problem.
>>>
>>> I found this problem because when I activate ISO for my webcam, I get
>>> below message
>>> "ERROR Transfer event TRB DMA ptr not part of current TD"
>>
>> Yes, but does the webcam work? Without the patch that you mentioned
>> below, you will get these messages, but they shouldn't cause any
>> functional problem.
>
> we will try to eliminate the message and check whether webcam is ok.
>
>> Also, which webcam is this? Maybe I can try to reproduce the problem
>> here.
>
> And normal uvc webcam will have this issue.(But you have to purposely
> disable "XHCI_SPURIOUS_SUCCESS")
?? Why would you purposely disable XHCI_SPURIOUS_SUCCESS? It is there
for a reason.
>> Which version of the kernel are you using? Please try this with the
>> latest version (3.16-rc5) to make sure this is not some problem that
>> has already been fixed.
>
> the version I use is 3.8.2.
> I will try to merge 3.16-rc5 into our system.
Good.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: Iso trbs for xhci arrangement
hi Paul My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? >>> >>> This looks like a hardware bug to me. Which xHCI controller is this? >> >> Synopsys > > Ouch ;) > the controller did fire iso in token to get 0x4fc bytes, above marked "", and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? >>> >>> I would bet that no data was transferred at all, but the controller >>> forgot to set the transfer length correctly for the chained normal TRB. >> >> so you mean the ISO will be sent but the chained normal TRB won't. >> that mean the host only get 0x4fc instead of total 0xbf4 Bytes. >> Am I right? > > No, I'm thinking that no data at all was received. That is what the Isoc > event TRB shows. But from isoc event TRB it shows there did get 0x4fc bytes from device, since the data length of event trb is not 0. > >>> Are you seeing an actual problem with this? If not, maybe the xHCI driver >>> is written in such a way that this does not cause a problem. >> >> I found this problem because when I activate ISO for my webcam, I get >> below message >> "ERROR Transfer event TRB DMA ptr not part of current TD" > > Yes, but does the webcam work? Without the patch that you mentioned > below, you will get these messages, but they shouldn't cause any > functional problem. we will try to eliminate the message and check whether webcam is ok. > > Also, which webcam is this? Maybe I can try to reproduce the problem > here. And normal uvc webcam will have this issue.(But you have to purposely disable "XHCI_SPURIOUS_SUCCESS") > > Which version of the kernel are you using? Please try this with the > latest version (3.16-rc5) to make sure this is not some problem that > has already been fixed. the version I use is 3.8.2. I will try to merge 3.16-rc5 into our system. > >> after tracing the src and checking the event TRB, I found the "TRB >> pointer" in event TRB is pointing to the chained normal TRB. >> And length of Event TRB is 0 but complete code is success. >> >>> 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 >>> >>> I doubt it. >>> appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 >>> >>> Are these the entire rings, or did you just show a part of them? >> >> Sure. >> I attach both event ring and ep ring at the end of mail. >> > Because all the TRBs have the cycle bit set, which shouldn't happen >> > AFAIK. >> Thanks for your kind help, > > Thanks, I will look at the ring data and see if I see anything suspicious. > > -- > Paul > >> event ring segment: >> platform-xhci.0: @278d1400 2796e240 0d000bf4 01038000 >> platform-xhci.0: @278d1410 2796e250 0d000bf4 01038000 >> platform-xhci.0: @278d1420 2796e260 0d000bf4 01038000 >> platform-xhci.0: @278d1430 2796e270 0d000bf4 01038000 >> platform-xhci.0: @278d1440 2796e280 0d000bf4 01038000 >> platform-xhci.0: @278d1450 2796e290 0d000bf4 01038000 >> platform-xhci.0: @278d1460 2796e2a0 0d000bf4 01038000 >> platform-xhci.0: @278d1470 2796e2b0 0d000bf4 01038000 >> platform-xhci.0: @278d1480 2796e2c0 0d000bf4 01038000 >> platform-xhci.0: @278d1490 2796e2d0 0d000bf4 010
RE: Iso trbs for xhci arrangement
> From: vichy [mailto:vichy@gmail.com] > Sent: Friday, July 18, 2014 10:13 AM > >>> Driver prepare ep ring like below >>> xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx >>> xhci.0: @2796e160 279d 06f8 0625 //normal >>> xhci.0: @2796e170 279d06f8 0bf4 80021625 >>> >>> but event ring get below result >>> xhci.0: @278d1710 2796e150 0d0004fc 01038001 >>> xhci.0: @278d1720 2796e160 0100 01038001 >>> //event for normal >>> >>> My questions are >>> 1. The xhci controller seems not handle the normal TRB for short package. >>>as you can see the length of event package for normal package is 0. >>>am I correct? >>> 2. if above #1 is correct, how xhci controller get the left 0x6f8 data >>>in original normal package? >> >> This looks like a hardware bug to me. Which xHCI controller is this? > > Synopsys Ouch ;) >>> the controller did fire iso in token to get 0x4fc bytes, above >>> marked "", and if xhci controller didn't firing the left in tokens >>> to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not >>> continuous, right? >> >> I would bet that no data was transferred at all, but the controller >> forgot to set the transfer length correctly for the chained normal TRB. > > so you mean the ISO will be sent but the chained normal TRB won't. > that mean the host only get 0x4fc instead of total 0xbf4 Bytes. > Am I right? No, I'm thinking that no data at all was received. That is what the Isoc event TRB shows. >> Are you seeing an actual problem with this? If not, maybe the xHCI driver >> is written in such a way that this does not cause a problem. > > I found this problem because when I activate ISO for my webcam, I get > below message > "ERROR Transfer event TRB DMA ptr not part of current TD" Yes, but does the webcam work? Without the patch that you mentioned below, you will get these messages, but they shouldn't cause any functional problem. Also, which webcam is this? Maybe I can try to reproduce the problem here. Which version of the kernel are you using? Please try this with the latest version (3.16-rc5) to make sure this is not some problem that has already been fixed. > after tracing the src and checking the event TRB, I found the "TRB > pointer" in event TRB is pointing to the chained normal TRB. > And length of Event TRB is 0 but complete code is success. > >> >>> 3. is there any relationship between below patch >>> https://lkml.org/lkml/2013/6/26/501 >> >> I doubt it. >> >>> appreciate your help, >>> >>> Endpoint 02 Context: >>> xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info >>> xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 >>> xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq >>> xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info >>> xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] >>> xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] >>> xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] >>> >>> ep ring >>> xhci.0: @2796e110 279ccb34 0bf4 80021625 >>> xhci.0: @2796e120 279cd728 0bf4 80021625 >>> xhci.0: @2796e130 279ce31c 0bf4 80021625 >>> xhci.0: @2796e140 279cef10 0bf4 80021625 >>> xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx >>> xhci.0: @2796e160 279d 06f8 0625 //normal >>> xhci.0: @2796e170 279d06f8 0bf4 80021625 >>> >>> event ring: >>> xhci.0: @278d1700 2796e140 0d000bf4 01038001 >>> xhci.0: @278d1710 2796e150 0d0004fc 01038001 >>> xhci.0: @278d1720 2796e160 0100 01038001 //event for >>> normal >>> xhci.0: @278d1730 2796e170 0d000bf4 01038001 >>> xhci.0: @278d1740 2796e180 0d000bf4 01038001 >> >> Are these the entire rings, or did you just show a part of them? > > Sure. > I attach both event ring and ep ring at the end of mail. > > Because all the TRBs have the cycle bit set, which shouldn't happen > > AFAIK. > Thanks for your kind help, Thanks, I will look at the ring data and see if I see anything suspicious. -- Paul > event ring segment: > platform-xhci.0: @278d1400 2796e240 0d000bf4 01038000 > platform-xhci.0: @278d1410 2796e250 0d000bf4 01038000 > platform-xhci.0: @278d1420 2796e260 0d000bf4 01038000 > platform-xhci.0: @278d1430 2796e270 0d000bf4 01038000 > platform-xhci.0: @278d1440 2796e280 0d000bf4 01038000 > platform-xhci.0: @278d1450 2796e290 0d000bf4 01038000 > platform-xhci.0: @278d1460 2796e2a0 0d000bf4 01038000 > platform-xhci.0: @278d1470 2796e2b0 0d000bf4 01038000 > platform-xhci.0: @278d1480 2796e2c0 0d000bf4 0103800
Re: Iso trbs for xhci arrangement
hi Paul: >> Driver prepare ep ring like below >> xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx >> xhci.0: @2796e160 279d 06f8 0625 //normal >> xhci.0: @2796e170 279d06f8 0bf4 80021625 >> >> but event ring get below result >> xhci.0: @278d1710 2796e150 0d0004fc 01038001 >> xhci.0: @278d1720 2796e160 0100 01038001 >> //event for normal >> >> My questions are >> 1. The xhci controller seems not handle the normal TRB for short package. >> as you can see the length of event package for normal package is 0. >> am I correct? >> 2. if above #1 is correct, how xhci controller get the left 0x6f8 data >> in original normal package? > > This looks like a hardware bug to me. Which xHCI controller is this? Synopsys > >> the controller did fire iso in token to get 0x4fc bytes, above >> marked "", and if xhci controller didn't firing the left in tokens >> to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not >> continuous, right? > > I would bet that no data was transferred at all, but the controller > forgot to set the transfer length correctly for the chained normal TRB. so you mean the ISO will be sent but the chained normal TRB won't. that mean the host only get 0x4fc instead of total 0xbf4 Bytes. Am I right? > > Are you seeing an actual problem with this? If not, maybe the xHCI driver > is written in such a way that this does not cause a problem. I found this problem because when I activate ISO for my webcam, I get below message "ERROR Transfer event TRB DMA ptr not part of current TD" after tracing the src and checking the event TRB, I found the "TRB pointer" in event TRB is pointing to the chained normal TRB. And length of Event TRB is 0 but complete code is success. > >> 3. is there any relationship between below patch >> https://lkml.org/lkml/2013/6/26/501 > > I doubt it. > >> appreciate your help, >> >> Endpoint 02 Context: >> xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info >> xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 >> xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq >> xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info >> xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] >> xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] >> xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] >> >> ep ring >> xhci.0: @2796e110 279ccb34 0bf4 80021625 >> xhci.0: @2796e120 279cd728 0bf4 80021625 >> xhci.0: @2796e130 279ce31c 0bf4 80021625 >> xhci.0: @2796e140 279cef10 0bf4 80021625 >> xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx >> xhci.0: @2796e160 279d 06f8 0625 //normal >> xhci.0: @2796e170 279d06f8 0bf4 80021625 >> >> event ring: >> xhci.0: @278d1700 2796e140 0d000bf4 01038001 >> xhci.0: @278d1710 2796e150 0d0004fc 01038001 >> xhci.0: @278d1720 2796e160 0100 01038001 //event for >> normal >> xhci.0: @278d1730 2796e170 0d000bf4 01038001 >> xhci.0: @278d1740 2796e180 0d000bf4 01038001 > > Are these the entire rings, or did you just show a part of them? Sure. I attach both event ring and ep ring at the end of mail. > Because all the TRBs have the cycle bit set, which shouldn't happen > AFAIK. Thanks for your kind help, event ring segment: platform-xhci.0: @278d1400 2796e240 0d000bf4 01038000 platform-xhci.0: @278d1410 2796e250 0d000bf4 01038000 platform-xhci.0: @278d1420 2796e260 0d000bf4 01038000 platform-xhci.0: @278d1430 2796e270 0d000bf4 01038000 platform-xhci.0: @278d1440 2796e280 0d000bf4 01038000 platform-xhci.0: @278d1450 2796e290 0d000bf4 01038000 platform-xhci.0: @278d1460 2796e2a0 0d000bf4 01038000 platform-xhci.0: @278d1470 2796e2b0 0d000bf4 01038000 platform-xhci.0: @278d1480 2796e2c0 0d000bf4 01038000 platform-xhci.0: @278d1490 2796e2d0 0d000bf4 01038000 platform-xhci.0: @278d14a0 2796e2e0 0d000bf4 01038000 platform-xhci.0: @278d14b0 2796e2f0 0d000bf4 01038000 platform-xhci.0: @278d14c0 2796e300 0d000bf4 01038000 platform-xhci.0: @278d14d0 2796e310 0d000bf4 01038000 platform-xhci.0: @278d14e0 2796e320 0d000bf4 01038000 platform-xhci.0: @278d14f0 2796e330 0d000bf4 01038000 platform-xhci.0: @278d1500 2796e340 0d000bf4 01038000 platform-xhci.0: @278d1510 2796e350 0d000bf4 01038000 platform-xhci.0: @278d1520 2796e360 0d0004fc 01038000 platform-xhci.0: @278d1530 2796e370 0100 0
RE: Iso trbs for xhci arrangement
> From: vichy [mailto:vichy@gmail.com] > Sent: Tuesday, July 15, 2014 1:42 AM > > > Please read section 3.2.11 in the xHCI spec, which is freely available on > > the web. > I found what you mean. > I dump "ep context", "ep ring" and "event ring" for handling short package. > > Driver prepare ep ring like below > xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx > xhci.0: @2796e160 279d 06f8 0625 //normal > xhci.0: @2796e170 279d06f8 0bf4 80021625 > > but event ring get below result > xhci.0: @278d1710 2796e150 0d0004fc 01038001 > xhci.0: @278d1720 2796e160 0100 01038001 > //event for normal > > My questions are > 1. The xhci controller seems not handle the normal TRB for short package. > as you can see the length of event package for normal package is 0. > am I correct? > 2. if above #1 is correct, how xhci controller get the left 0x6f8 data > in original normal package? This looks like a hardware bug to me. Which xHCI controller is this? > the controller did fire iso in token to get 0x4fc bytes, above > marked "", and if xhci controller didn't firing the left in tokens > to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not > continuous, right? I would bet that no data was transferred at all, but the controller forgot to set the transfer length correctly for the chained normal TRB. Are you seeing an actual problem with this? If not, maybe the xHCI driver is written in such a way that this does not cause a problem. > 3. is there any relationship between below patch > https://lkml.org/lkml/2013/6/26/501 I doubt it. > appreciate your help, > > Endpoint 02 Context: > xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info > xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 > xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq > xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info > xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] > xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] > xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] > > ep ring > xhci.0: @2796e110 279ccb34 0bf4 80021625 > xhci.0: @2796e120 279cd728 0bf4 80021625 > xhci.0: @2796e130 279ce31c 0bf4 80021625 > xhci.0: @2796e140 279cef10 0bf4 80021625 > xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx > xhci.0: @2796e160 279d 06f8 0625 //normal > xhci.0: @2796e170 279d06f8 0bf4 80021625 > > event ring: > xhci.0: @278d1700 2796e140 0d000bf4 01038001 > xhci.0: @278d1710 2796e150 0d0004fc 01038001 > xhci.0: @278d1720 2796e160 0100 01038001 //event for > normal > xhci.0: @278d1730 2796e170 0d000bf4 01038001 > xhci.0: @278d1740 2796e180 0d000bf4 01038001 Are these the entire rings, or did you just show a part of them? Because all the TRBs have the cycle bit set, which shouldn't happen AFAIK. -- Paul
Re: Iso trbs for xhci arrangement
hi Paul: > Please read section 3.2.11 in the xHCI spec, which is freely available on > the web. I found what you mean. I dump "ep context", "ep ring" and "event ring" for handling short package. Driver prepare ep ring like below xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 but event ring get below result xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal My questions are 1. The xhci controller seems not handle the normal TRB for short package. as you can see the length of event package for normal package is 0. am I correct? 2. if above #1 is correct, how xhci controller get the left 0x6f8 data in original normal package? the controller did fire iso in token to get 0x4fc bytes, above marked "", and if xhci controller didn't firing the left in tokens to get 0x6f8 bytes, that mean the data we get from iso-in pipe is not continuous, right? 3. is there any relationship between below patch https://lkml.org/lkml/2013/6/26/501 appreciate your help, Endpoint 02 Context: xhci.0: @e52e90c0 (virt) @27f660c0 (dma) 0x01 - ep_info xhci.0: @e52e90c4 (virt) @27f660c4 (dma) 0x3fc0228 - ep_info2 xhci.0: @e52e90c8 (virt) @27f660c8 (dma) 0x2796e001 - deq xhci.0: @e52e90d0 (virt) @27f660d0 (dma) 0xbf40bf4 - tx_info xhci.0: @e52e90d4 (virt) @27f660d4 (dma) 0x00 - rsvd[0] xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x00 - rsvd[1] xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x300 - rsvd[2] ep ring xhci.0: @2796e110 279ccb34 0bf4 80021625 xhci.0: @2796e120 279cd728 0bf4 80021625 xhci.0: @2796e130 279ce31c 0bf4 80021625 xhci.0: @2796e140 279cef10 0bf4 80021625 xhci.0: @2796e150 279cfb04 000404fc 80021415 //xx xhci.0: @2796e160 279d 06f8 0625 //normal xhci.0: @2796e170 279d06f8 0bf4 80021625 event ring: xhci.0: @278d1700 2796e140 0d000bf4 01038001 xhci.0: @278d1710 2796e150 0d0004fc 01038001 xhci.0: @278d1720 2796e160 0100 01038001 //event for normal xhci.0: @278d1730 2796e170 0d000bf4 01038001 xhci.0: @278d1740 2796e180 0d000bf4 01038001 -- 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: Iso trbs for xhci arrangement
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of vichy
>
> hi all:
> when I trace xhci_queue_isoc_tx, I found ISO TD should look like
> ISO TRB --> Normal TRB --> Normal TRB
> But when I dump ep segment during Iso transfer I get below result
> 1. Why most of them are ISO TRBs?
> 2. Why there is only 1 normal TRB
>
> appreciate your help in advance,
Please read section 3.2.11 in the xHCI spec, which is freely available on
the web.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
