Re: spec violation of xHCI?

On 12/12/13 01:59, Kohji Okuno wrote:
> From: Hans Petter Selasky <hps_at_bitfrost.no>
> Date: Wed, 11 Dec 2013 15:04:42 +0100
>> On 12/11/13 14:06, Kohji Okuno wrote:
>>>
>>> Hi HPS,
>>>
>>> All link trbs which are not the end need CHAIN bit, I think.
>>> But, this is errata in xHCI ver 0.95. So, linux has quirk for chain
>>> bit. Could you check linux codes?
>>>
>>> Regards,
>>>    Kohji Okuno
>>
>> Hi Kohji,
>>
>> I went through the Linux codes a bit, and I see they have some quirks for the
>> chaining bit. Unfortunately Linux does the queuing quite differently than in
>> FreeBSD and Shara Sharp which is the author of that code, stated recently a
>> need for rewrite of the TRB/TD stuff in Linux, so I'm not sure if that means
>> there are more bugs in there or not. Let me explain a bit how things work in
>> FreeBSD and why I did not put the chaining bit in line 1895 which you suggest.
>>
>> In my design the chaining bit should not be set at line 1895, because if you
>> receive a short packet and nframes > 1, the XHCI should not go to the end of
>> the frame list, but rather the next frame, nframes + 1.
>>
>> If the single short OK flag is set on a BULK transfer, yes, it would be
>> correct to set the chaining bit here, but it is not required, because we are
>> already are handling activation of the next frame in the function
>> "xhci_activate_transfer()" and "xhci_skip_transfer()". Transfer here means
>> zero or more TRBs. We use the cycle bit on the TRB to single step the frames
>> in software, although you are right that we might optimise this by setting the
>> chaining bit instead for the BULK case so that we don't need software
>> intervention to handle the job.
>>
>> If the multi short OK flag is set, multiple short terminated frames can be
>> received and then the chaining bit should not be set.
>>
>> Are you seeing a real problem because of the chain bit not being set, or is
>> this more the result of code review?
>>
>> Thank you for the interest in my XHCI driver.
>>
>> --HPS
>
> Hi HPS,
>
> Unfortunately, I can not explain in detail. But, I encountered a real
> problem for ZLP. And, when I added CHAIN bit, this problem was
> resolved.
>
> When a device driver needs force_short(ZLP), your device driver
> creates TRB in the followings.
>
> NORMAL_TRB    - LINK_TRB - NORMAL_TRB - LINK_TRB   => Kick DOORBELL
> (with payload)   (#1)      (ZLP)        (#2)
>
> In this case, I think LINK_TRB #1 needs chain bit.

Hi Kohji,

Did you check using a USB analyzer what the difference is when setting 
the CHAIN bit and not setting the chain bit?

I would guess that if you set the CHAIN-bit in this case, no ZLP will be 
sent, because the TRB is associated with the previous one.

What endpoint type is this? BULK/CONTROL/INTR/ISOC

What direction is this? IN or OUT?

--HPS