From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751443AbcJZE2U (ORCPT ); Wed, 26 Oct 2016 00:28:20 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:35489 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750864AbcJZE2S (ORCPT ); Wed, 26 Oct 2016 00:28:18 -0400 MIME-Version: 1.0 In-Reply-To: <57E0F2CD.2000302@linux.intel.com> References: <20160919063545.2055-1-joel@jms.id.au> <57DF969B.8030204@linux.intel.com> <57E0F2CD.2000302@linux.intel.com> From: Joel Stanley Date: Wed, 26 Oct 2016 14:57:36 +1030 X-Google-Sender-Auth: JTUJ02R7iZN2EIfXarwcD3r7nAE Message-ID: Subject: Re: [RFC PATCH] xhci: do not halt the secondary HCD To: Mathias Nyman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, Benjamin Herrenschmidt , Sam Mendoza-Jonas Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 20, 2016 at 5:56 PM, Mathias Nyman wrote: > Quick Googling shows that that TI TUSB 73x0 USB3.0 xHCI host has an issue > with halting. > > Errata says host needs 125us to 1ms between the last control transfer and > clearing the run/stop bit. (halting the host) > > Suggested workaround is to wait at least 2ms before halting the host. > > See issue #10 in: > http://www.ti.com/lit/er/sllz076/sllz076.pdf > > It might just be that the patch works because it forces halting the host to > be done later (secondary hcd -> primary hcd), giving it enough time after > the last control transfer. Well spotted. I gave this a go, adding a quirk and performing a msleep: +++ b/drivers/usb/host/xhci.c @@ -109,6 +109,10 @@ int xhci_halt(struct xhci_hcd *xhci) { int ret; xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Halt the HC"); + + if (xhci->quirks & XHCI_HALT_DELAY_QUIRK) + msleep(2); + xhci_quiesce(xhci); However it didn't help. Are we guaranteed that transfers are not in flight at that point? > >>> a first step. >>> >>> load primary >>> load secondary (starts the xhci controller >>> ... >>> unload secondary (halts the controller) >>> unload primary (free memory) > > > Now thinking about it, it doesn't really make sense to halt the host > controller hardware > before removing the primary hcd. It will just cause devices under the > primary (USB2) to > be removed uncleanly. So basically the idea of the workaround makes sense, > it just needs > to be cleaned up from a workaround to intended behavior. Great. When you say clean up, do you just mean tidying the comments? Cheers, Joel > > We might also need an additional quirk for TI TUSB 73x0 that adds a msleep() > before the > xhci_halt, even if it's moved to the last hcd removed. > > -Mathias