RE: Iso trbs for xhci arrangement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: vichy [mailto:vichy.kuo@xxxxxxxxx]
> 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: @000000002796e150 279cfb04 00000000 000404fc 80021415  //xxxxxx
>     xhci.0: @000000002796e160 279d0000 00000000 000006f8 00000625  //normal
>     xhci.0: @000000002796e170 279d06f8 00000000 00000bf4 80021625
> 
>     but event ring get below result
>     xhci.0: @00000000278d1710 2796e150 00000000 0d0004fc 01038001
>     xhci.0: @00000000278d1720 2796e160 00000000 01000000 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 "xxxx", 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) 0x000001 - 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) 0x000000 - rsvd[0]
> xhci.0: @e52e90d8 (virt) @27f660d8 (dma) 0x000000 - rsvd[1]
> xhci.0: @e52e90dc (virt) @27f660dc (dma) 0x3000000 - rsvd[2]
> 
> ep ring
> xhci.0: @000000002796e110 279ccb34 00000000 00000bf4 80021625
> xhci.0: @000000002796e120 279cd728 00000000 00000bf4 80021625
> xhci.0: @000000002796e130 279ce31c 00000000 00000bf4 80021625
> xhci.0: @000000002796e140 279cef10 00000000 00000bf4 80021625
> xhci.0: @000000002796e150 279cfb04 00000000 000404fc 80021415  //xxxxxx
> xhci.0: @000000002796e160 279d0000 00000000 000006f8 00000625  //normal
> xhci.0: @000000002796e170 279d06f8 00000000 00000bf4 80021625
> 
> event ring:
> xhci.0: @00000000278d1700 2796e140 00000000 0d000bf4 01038001
> xhci.0: @00000000278d1710 2796e150 00000000 0d0004fc 01038001
> xhci.0: @00000000278d1720 2796e160 00000000 01000000 01038001 //event for normal
> xhci.0: @00000000278d1730 2796e170 00000000 0d000bf4 01038001
> xhci.0: @00000000278d1740 2796e180 00000000 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

��.n��������+%������w��{.n�����{���)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥





[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux