From patchwork Fri Jan 29 02:20:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 8157591 Return-Path: X-Original-To: patchwork-linux-rockchip@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id AF8119FE6C for ; Fri, 29 Jan 2016 02:21:27 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B29C520265 for ; Fri, 29 Jan 2016 02:21:26 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8E52220375 for ; Fri, 29 Jan 2016 02:21:25 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1aOygf-0006uc-3x; Fri, 29 Jan 2016 02:21:25 +0000 Received: from merlin.infradead.org ([2001:4978:20e::2]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1aOygS-0006oF-0m for linux-rockchip@bombadil.infradead.org; Fri, 29 Jan 2016 02:21:12 +0000 Received: from mail-pf0-x232.google.com ([2607:f8b0:400e:c00::232]) by merlin.infradead.org with esmtps (Exim 4.85 #2 (Red Hat Linux)) id 1aOygQ-00080D-9l for linux-rockchip@lists.infradead.org; Fri, 29 Jan 2016 02:21:10 +0000 Received: by mail-pf0-x232.google.com with SMTP id 65so33460765pfd.2 for ; Thu, 28 Jan 2016 18:20:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=mUsZ6YbWZuOwU1agXz6k0NpfoDt2OmuINP6XNDfAGqI=; b=Y8bCZ4OIup8oILiiIRRhXjAhmIR/h43qKioZMo5qwX3VkkPKni/6nGAoWSMuh7Bovm E6YK2KssNMSt2A5hP6Ih6wP+/t9CNIxjcc+3GPMw7F2S6ZpnJSs7qZ6EnraJv7LGrt/W bxTjZMYBJwr9VV2xkMr9HUQwoJivh/Atoz77c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=mUsZ6YbWZuOwU1agXz6k0NpfoDt2OmuINP6XNDfAGqI=; b=V6EksF40dlBOBzRnBC+oiJ4ZTCYlr6ZTU+GGGb5PC0zjnT+DpcjQ8KBDMB/KNuqs7u Cc+aw+2DNxrnDd8ugIrEHvsarZ27LKbx2QlASVfUPI9IT3JYvHMZuImVCypZI1BU94nY GkSnHUPFRqGhEPf/a6VAHNvInX5gJOlWR0kt02s90ybkG+ptabbGPqTorNhJP4efDI/G ejMUjqfhwuwQz+5qddgrjwZiCO3Br6PmzTzowP8FQQ7T8jgAHrCaByvf4qlJeLVFnTom 52laUEX+w2S+EQskk7qL4b8FXJJwfLjig7RC527KsASDfPyAObLYWomXflMjpWZx+U6l r6ig== X-Gm-Message-State: AG10YORrmUCSp7M6wbuCi1AZvE8KmdTHpljM0wpfmxA/aU8Kbx49WZgz9Aeji4AE+sHqpQ== X-Received: by 10.98.31.84 with SMTP id f81mr9675940pff.98.1454034048576; Thu, 28 Jan 2016 18:20:48 -0800 (PST) Received: from tictac.mtv.corp.google.com ([172.22.65.76]) by smtp.gmail.com with ESMTPSA id ux2sm19314864pac.46.2016.01.28.18.20.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 18:20:48 -0800 (PST) From: Douglas Anderson To: John Youn , balbi@ti.com, kever.yang@rock-chips.com Subject: [PATCH v6 11/22] usb: dwc2: host: There's not really a TT for the root hub Date: Thu, 28 Jan 2016 18:20:02 -0800 Message-Id: <1454034013-24657-12-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.7.0.rc3.207.g0ac5344 In-Reply-To: <1454034013-24657-1-git-send-email-dianders@chromium.org> References: <1454034013-24657-1-git-send-email-dianders@chromium.org> X-MIME-Error: demime acl condition: uuencoded line length is not a multiple of 4 characters X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20160128_212110_486007_DC1FFCC8 X-CRM114-Status: GOOD ( 19.23 ) X-Spam-Score: -2.7 (--) X-BeenThere: linux-rockchip@lists.infradead.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Upstream kernel work for Rockchip platforms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: huangtao@rock-chips.com, stefan.wahren@i2se.com, heiko@sntech.de, johnyoun@synopsys.com, gregkh@linuxfoundation.org, ming.lei@canonical.com, linux-usb@vger.kernel.org, Douglas Anderson , linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, yousaf.kaukab@intel.com, stern@rowland.harvard.edu, linux-rpi-kernel@lists.infradead.org, gregory.herrero@intel.com, william.wu@rock-chips.com, Julius Werner , dinguyen@opensource.altera.com MIME-Version: 1.0 Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+patchwork-linux-rockchip=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP I find that when I plug a full speed (NOT high speed) hub into a dwc2 port and then I plug a bunch of devices into that full speed hub that dwc2 goes bat guano crazy. Specifically, it just spews errors like this in the console: usb usb1: clear tt 1 (9043) error -22 The specific test case I used looks like this: /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 17, If 0, Class=Hub, Driver=hub/4p, 12M |__ Port 2: Dev 19, If 0, ..., Driver=usbhid, 1.5M |__ Port 4: Dev 20, If 0, ..., Driver=usbhid, 12M |__ Port 4: Dev 20, If 1, ..., Driver=usbhid, 12M |__ Port 4: Dev 20, If 2, ..., Driver=usbhid, 12M Showing VID/PID: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 017: ID 03eb:3301 Atmel Corp. at43301 4-Port Hub Bus 001 Device 020: ID 045e:0745 Microsoft Corp. Nano Transceiver ... Bus 001 Device 019: ID 046d:c404 Logitech, Inc. TrackMan Wheel I spent a bunch of time trying to figure out why there are errors to begin with. I believe that the issue may be a hardware issue where the transceiver sometimes accidentally sends a PREAMBLE packet if you send a packet to a full speed device right after one to a low speed device. Luckily the USB driver retries and the second time things work OK. In any case, things kinda seem work despite the errors, except for the "clear tt" spew mucking up my console. Chalk it up for a win for retries and robust protocols. So getting back to the "clear tt" problem, it appears that we get those because there's not actually a TT here to clear. It's my understanding that when dwc2 operates in low speed or full speed mode that there's no real TT out there. That makes all these attempts to "clear the TT" somewhat meaningless and also causes the spew in the log. Let's just skip all the useless TT clears. Eventually we should root cause the errors, but even if we do this is still a proper fix and is likely to avoid the "clear tt" error in the future. Note that hooking up a Full Speed USB Audio Device (Jabra 510) to this same hub with the keyboard / trackball shows that even audio works over this janky connection. As a point to note, this particular change (skip bogus TT clears) compared to just commenting out the dev_err() in hub_tt_work() actually produces better audio. Note: don't ask me where I got a full speed USB hub or whether the massive amount of dust that accumulated on it while it was in my junk box affected its funtionality. Just smile and nod. Signed-off-by: Douglas Anderson Reviewed-by: Kever Yang --- Changes in v6: - There's not really a TT for the root hub new for v6 Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None drivers/usb/dwc2/hcd_intr.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c index 5d25a5ec9736..fe44870f84eb 100644 --- a/drivers/usb/dwc2/hcd_intr.c +++ b/drivers/usb/dwc2/hcd_intr.c @@ -87,6 +87,7 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg *hsotg, struct dwc2_host_chan *chan, struct dwc2_qtd *qtd) { + struct usb_device *root_hub = dwc2_hsotg_to_hcd(hsotg)->self.root_hub; struct urb *usb_urb; if (!chan->qh) @@ -102,6 +103,15 @@ static void dwc2_hc_handle_tt_clear(struct dwc2_hsotg *hsotg, if (!usb_urb || !usb_urb->dev || !usb_urb->dev->tt) return; + /* + * The root hub doesn't really have a TT, but Linux thinks it + * does because how could you have a "high speed hub" that + * directly talks directly to low speed devices without a TT? + * It's all lies. Lies, I tell you. + */ + if (usb_urb->dev->tt->hub == root_hub) + return; + if (qtd->urb->status != -EPIPE && qtd->urb->status != -EREMOTEIO) { chan->qh->tt_buffer_dirty = 1; if (usb_hub_clear_tt_buffer(usb_urb))