From owner-freebsd-usb@FreeBSD.ORG Wed Dec 11 14:03:37 2013 Return-Path: Delivered-To: freebsd-usb@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 605E8B15; Wed, 11 Dec 2013 14:03:37 +0000 (UTC) Received: from mta05.bitpro.no (mta05.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 194491E4D; Wed, 11 Dec 2013 14:03:36 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta05.bitpro.no (Postfix) with ESMTPS id 1EFB117FC96; Wed, 11 Dec 2013 15:03:34 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id DDFD98FEA6B; Wed, 11 Dec 2013 15:04:13 +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 10iJJeW0tSts; Wed, 11 Dec 2013 15:04:13 +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 0F30C8FEA6A; Wed, 11 Dec 2013 15:04:13 +0100 (CET) Message-ID: <52A870FA.5080803@bitfrost.no> Date: Wed, 11 Dec 2013 15:04:42 +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.201213.2095490882413924223.okuno.kohji@jp.panasonic.com> <52A85E35.6000508@bitfrost.no> <52A85FAA.8030402@bitfrost.no> <20131211.220615.1986324315440989553.okuno.kohji@jp.panasonic.com> In-Reply-To: <20131211.220615.1986324315440989553.okuno.kohji@jp.panasonic.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:03:37 -0000 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