From owner-freebsd-current@FreeBSD.ORG Thu Dec 12 07:40:40 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 6541EAAF; Thu, 12 Dec 2013 07:40:40 +0000 (UTC) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 1885F154E; Thu, 12 Dec 2013 07:40:39 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id rBC7eZ0O029598; Thu, 12 Dec 2013 16:40:35 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili11) with ESMTP id rBC7eaR31318; Thu, 12 Dec 2013 16:40:36 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id rBC7eah1006473; Thu, 12 Dec 2013 16:40:36 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id rBC7eZfa006435; Thu, 12 Dec 2013 16:40:35 +0900 Date: Thu, 12 Dec 2013 16:40:35 +0900 (JST) Message-Id: <20131212.164035.965182632628711738.okuno.kohji@jp.panasonic.com> To: hps@bitfrost.no Subject: Re: spec violation of xHCI? From: Kohji Okuno In-Reply-To: <52A96276.3060203@bitfrost.no> References: <52A870FA.5080803@bitfrost.no> <20131212.095958.798647707277033359.okuno.kohji@jp.panasonic.com> <52A96276.3060203@bitfrost.no> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, okuno.kohji@jp.panasonic.com, 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: Thu, 12 Dec 2013 07:40:40 -0000 From: Hans Petter Selasky Date: Thu, 12 Dec 2013 08:15:02 +0100 > 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 Hi HPS, The endpoint type is BULK, and the direction is OUT. I checked by using a USB analyzer. When I did not set CHAIN bit in LINK TRB, my host controller sent illegal packets sometimes. But, ZLPs were sent. Regards, Kohji Okuno