From: Hans Petter Selasky <h...@bitfrost.no>
Date: Thu, 12 Dec 2013 08:15:02 +0100
> On 12/12/13 01:59, Kohji Okuno wrote:
>> From: Hans Petter Selasky <h...@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?
>>>> Kohji Okuno
>>> Hi Kohji,
>>> I went through the Linux codes a bit, and I see they have some quirks for
>>> chaining bit. Unfortunately Linux does the queuing quite differently than
>>> 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
>>> there are more bugs in there or not. Let me explain a bit how things work
>>> FreeBSD and why I did not put the chaining bit in line 1895 which you
>>> In my design the chaining bit should not be set at line 1895, because if
>>> receive a short packet and nframes > 1, the XHCI should not go to the end
>>> 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
>>> 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
>>> in software, although you are right that we might optimise this by setting
>>> 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.
>> 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
>> 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?
The endpoint type is BULK, and the direction is OUT.
I checked by using a USB analyzer. When I did not set CHAIN bit in
LINK TRB, my host controller sent illegal packets sometimes.
But, ZLPs were sent.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"