spec violation of xHCI?
Hans Petter Selasky
hps at bitfrost.no
Wed Dec 11 12:43:32 UTC 2013
On 12/11/13 12:12, Kohji Okuno wrote:
>> On 12/11/13 11:12, Kohji Okuno wrote:
>>> Hi,
>>>
>>> I think the xHCI host controller driver has a spec violation.
>>>
>>> Could you refer to
>>> ``Table 126: Offset 0Ch – Link TRB Field Definitions''
>>> in xHCI_Specification_for_USB.pdf(Revision 1.0)?
>>>
>>> The following is an excerpt about the CHAIN BIT.
>>>
>>> Chain bit (CH). Set to ‘1’ by software to associate this TRB with
>>> the next TRB on the Ring. A Transfer Descriptor (TD) is defined as
>>> one or more TRBs. The Chain bit is used to identify the TRBs that
>>> comprise a TD. Refer to section 4.11.7 for more information on Link
>>> TRB placement within a TD. On a Command Ring this bit is ignored by
>>> the xHC.
>>>
>>>
>>> I think that we should add XHCI_TRB_3_CHAIN_BIT to line 1895.
>>> How do you think?
>>>
>>
>> Hi Kohji,
>>
>> The double word written at line 1895 does not set the "chain bit" because this
>> is the end of a transfer descriptor, TD. I'm unsure how hardware interprets
>> this bit, if setting the bit on the previous TRB makes the next one connect to
>> the previous one, or the other way around. If setting this bit makes the TRB
>> connect to the previous one, you are correct. Else the current code is
>> correct.
>
> Hi, HPS,
>
> Thank you for your comment.
>
> I think that this (line 1895) is not the end of a transfer descriptor.
> When the device driver needs a Zero Length Packet, this is not the
> end. And, If xfer has nframes, this is not the end, too.
>
> Regards,
> Kohji Okuno
>
Hi Kohji,
Yes, you are right that if nframes is greater than one, and/or if a ZLP
needs to be sent this is not the end of the USB transfers. Are we sure
that if the XHCI_TRB_3_CHAIN_BIT is added at line 1895, that we will
receive a completion TRB-event for each of the nframes, or will the
chain bit result in loss of TRB completion events?
Does setting this bit have any impact on performance?
Thank you!
--HPS
More information about the freebsd-current
mailing list