From owner-freebsd-current@FreeBSD.ORG Mon Sep 22 06:02:57 2014 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 79363D6; Mon, 22 Sep 2014 06:02:57 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34D19EFF; Mon, 22 Sep 2014 06:02:56 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 7EF4D1FE027; Mon, 22 Sep 2014 08:02:53 +0200 (CEST) Message-ID: <541FBB84.6050508@selasky.org> Date: Mon, 22 Sep 2014 08:02:44 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Kohji Okuno , freebsd-current@freebsd.org Subject: Re: Does the xHCI driver has a spec violation? References: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> In-Reply-To: <20140922.135800.1954695532570247771.okuno.kohji@jp.panasonic.com> Content-Type: multipart/mixed; boundary="------------020008010507050400020707" Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 22 Sep 2014 06:02:57 -0000 This is a multi-part message in MIME format. --------------020008010507050400020707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/22/14 06:58, Kohji Okuno wrote: > Hi, > > I encountered a issue for USB mic. > > In fist time, my host controller (xHCI) sends single IN-tokens every > 8-SOFs. This is expected action. But, after I open, close and open, my > host controller sends plural IN-tokens between SOF and SOF. > > In Intel Lynx Point, I could not reproduce this issue. > I'm sorry. Unfortunately, I can't explain details about my proprietary > host controler. > > I found the following explanation in the xHCI 1.1 specification > http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/extensible-host-controler-interface-usb-xhci.pdf > > In 4.8.3 Endpoint Context State, > 6. The Configure Endpoint Command (Add (A) = `1' and Drop (D) =`1') > shall transition an endpoint, except the Default Control > Endpoint, from the Stopped to the Running state.' > > > So, I modify as the following, then I can run expectedly. > What do you think about this change? Hi, I think we should issue the context drop separately. Are we certain that if both drop and add bits are set at the same time, that the drop bit will be processed before the add? This might be a bug in your hardware, which apparently doesn't check if the context has already been added or not. I'll be glad to make a workaround for it once we have settled on a solution. Can you test the attached patch using both your hardware and the Lynx Point. Thank you! --HPS > > Best regards, > Kohji Okuno --------------020008010507050400020707 Content-Type: text/x-diff; name="xhci.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xhci.diff" === ./xhci.c ================================================================== --- ./xhci.c (revision 271878) +++ ./xhci.c (local) @@ -3805,7 +3805,17 @@ * Get the endpoint into the running state according to the * endpoint context state diagram in the XHCI specification: */ + if (epno > 1) { + /* need to disable endpoint context first */ + xhci_configure_mask(udev, (1U << epno), 1); + + err = xhci_cmd_evaluate_ctx(sc, buf_inp.physaddr, index); + + if (err != 0) + DPRINTF("Could not configure endpoint %u\n", epno); + } + xhci_configure_mask(udev, (1U << epno) | 1U, 0); err = xhci_cmd_evaluate_ctx(sc, buf_inp.physaddr, index); --------------020008010507050400020707--