From owner-freebsd-current@FreeBSD.ORG Wed Dec 11 12:49:44 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B6866C; Wed, 11 Dec 2013 12:49:44 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id C8BDC14D6; Wed, 11 Dec 2013 12:49:43 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id 6F5D517FC6C; Wed, 11 Dec 2013 13:49:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 306388FC864; Wed, 11 Dec 2013 13:50:22 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0K6WX-pewfQ; Wed, 11 Dec 2013 13:50:21 +0100 (CET) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id 525368FC58F; Wed, 11 Dec 2013 13:50:21 +0100 (CET) Message-ID: <52A85FAA.8030402@bitfrost.no> Date: Wed, 11 Dec 2013 13:50:50 +0100 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kohji Okuno Subject: Re: spec violation of xHCI? References: <20131211.191212.1888965979017331164.okuno.kohji@jp.panasonic.com> <52A844D6.7050203@bitfrost.no> <20131211.201213.2095490882413924223.okuno.kohji@jp.panasonic.com> <52A85E35.6000508@bitfrost.no> In-Reply-To: <52A85E35.6000508@bitfrost.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 12:49:44 -0000 On 12/11/13 13:44, Hans Petter Selasky wrote: > 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 Some more thoughts: The code in question handle all four USB transfer types. Are you saying that the CHAIN bit should be set for isochronous transfers too, so all the packets send in all the intervals are chained together? Or is this only for BULK traffic you want to add the CHAIN bit? Thank you! --HPS