From owner-freebsd-usb@FreeBSD.ORG Thu Dec 12 07:14:05 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 B4106571; Thu, 12 Dec 2013 07:14:05 +0000 (UTC) Received: from mta04.bitpro.no (mta04.bitpro.no [92.42.64.203]) by mx1.freebsd.org (Postfix) with ESMTP id 3AE741333; Thu, 12 Dec 2013 07:14:04 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta04.bitpro.no (Postfix) with ESMTPS id E1A9F100592; Thu, 12 Dec 2013 08:13:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 851938FEB0A; Thu, 12 Dec 2013 08:14:36 +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 Dodl1i7Uw2uf; Thu, 12 Dec 2013 08:14:35 +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 4CE7D8FEB09; Thu, 12 Dec 2013 08:14:35 +0100 (CET) Message-ID: <52A96276.3060203@bitfrost.no> Date: Thu, 12 Dec 2013 08:15:02 +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: <52A85FAA.8030402@bitfrost.no> <20131211.220615.1986324315440989553.okuno.kohji@jp.panasonic.com> <52A870FA.5080803@bitfrost.no> <20131212.095958.798647707277033359.okuno.kohji@jp.panasonic.com> In-Reply-To: <20131212.095958.798647707277033359.okuno.kohji@jp.panasonic.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Thu, 12 Dec 2013 07:14:05 -0000 On 12/12/13 01:59, Kohji Okuno wrote: > From: Hans Petter Selasky > 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? >>> >>> 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 > > 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 > resolved. > > 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? --HPS