Date: Thu, 12 Dec 2013 16:40:35 +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.164035.965182632628711738.okuno.kohji@jp.panasonic.com> In-Reply-To: <52A96276.3060203@bitfrost.no> References: <52A870FA.5080803@bitfrost.no> <20131212.095958.798647707277033359.okuno.kohji@jp.panasonic.com> <52A96276.3060203@bitfrost.no>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Hans Petter Selasky <hps@bitfrost.no> Date: Thu, 12 Dec 2013 08:15:02 +0100 > On 12/12/13 01:59, Kohji Okuno wrote: >> 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. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131212.164035.965182632628711738.okuno.kohji>