From owner-freebsd-current@FreeBSD.ORG Wed Dec 11 12:43:32 2013 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3479E36; Wed, 11 Dec 2013 12:43:32 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6CE18147A; Wed, 11 Dec 2013 12:43:32 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id A58A717FC60; Wed, 11 Dec 2013 13:43:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 636128FAD3B; Wed, 11 Dec 2013 13:44:09 +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 lFYAb9fixbUT; Wed, 11 Dec 2013 13:44:08 +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 44C0A8FAD39; Wed, 11 Dec 2013 13:44:08 +0100 (CET) Message-ID: <52A85E35.6000508@bitfrost.no> Date: Wed, 11 Dec 2013 13:44:37 +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> In-Reply-To: <20131211.201213.2095490882413924223.okuno.kohji@jp.panasonic.com> 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:43:32 -0000 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