Date: Thu, 12 Dec 2013 09:59:58 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: hps@bitfrost.no Cc: freebsd-current@FreeBSD.org, okuno.kohji@jp.panasonic.com, freebsd-usb@freebsd.org Subject: Re: spec violation of xHCI? Message-ID: <20131212.095958.798647707277033359.okuno.kohji@jp.panasonic.com> In-Reply-To: <52A870FA.5080803@bitfrost.no> References: <52A85FAA.8030402@bitfrost.no> <20131211.220615.1986324315440989553.okuno.kohji@jp.panasonic.com> <52A870FA.5080803@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Hans Petter Selasky <hps@bitfrost.no> 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. Regards, Kohji Okuno
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131212.095958.798647707277033359.okuno.kohji>