From patchwork Mon Aug 4 09:34:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Roger Quadros X-Patchwork-Id: 34821 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 5905B21F5F for ; Mon, 4 Aug 2014 09:34:42 +0000 (UTC) Received: by mail-oi0-f71.google.com with SMTP id e131sf34669031oig.2 for ; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe :content-type:content-transfer-encoding; bh=fHAGGU1SSL+hmby2rCSI2MrxpwJrDBBLQsASzf4+1hI=; b=I9MPLd1Jlqr50AC34G/Nt//mmMyC/k8uxLp+99fOzX3fS+jv/pMZ1tQKSEVPak3RKi zB74dYtBfC0LmhHZhDNxuOoOOCNNqSRcfy/l7ROmH53GVTagBUjd4Ol8tkPNltcNGyKU P7+CvCQn/z5whlfmOpcE0L6RWjAw9Lfs1EpuKMfUfs39dSyF/NQIlA9/wbJkhMuFql0L OhbhZEqDe0BmCdvuUxeEMe0hlB2TAneABLZM+fSK7IQdihuf5S0KZNgNAer/JzW4Tr4b uCvyhpunZLfQUWCO2BwkanX66dtWOC0iiXI4UVaENEPC2QXTkKZGOVn8U90MYQj9KPoG vNXQ== X-Gm-Message-State: ALoCoQmMqwIVX9snwUyPebzqxdnJJPIRT8bS65B+4l+I/dE773c9vSki32bbd+azPy05blIqgVyH X-Received: by 10.182.29.10 with SMTP id f10mr8407147obh.23.1407144880778; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.25.144 with SMTP id 16ls2138537qgt.45.gmail; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) X-Received: by 10.221.56.5 with SMTP id wa5mr21970726vcb.25.1407144880618; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by mx.google.com with ESMTPS id jr10si11599129veb.21.2014.08.04.02.34.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 02:34:40 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.180 as permitted sender) client-ip=209.85.220.180; Received: by mail-vc0-f180.google.com with SMTP id ij19so10574149vcb.11 for ; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) X-Received: by 10.220.50.8 with SMTP id x8mr22139620vcf.18.1407144880387; Mon, 04 Aug 2014 02:34:40 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.221.37.5 with SMTP id tc5csp290708vcb; Mon, 4 Aug 2014 02:34:39 -0700 (PDT) X-Received: by 10.66.120.176 with SMTP id ld16mr7527709pab.84.1407144879037; Mon, 04 Aug 2014 02:34:39 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id xo4si16956515pbc.250.2014.08.04.02.34.38 for ; Mon, 04 Aug 2014 02:34:39 -0700 (PDT) Received-SPF: none (google.com: linux-omap-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752085AbaHDJef (ORCPT + 6 others); Mon, 4 Aug 2014 05:34:35 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:51821 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751529AbaHDJed (ORCPT ); Mon, 4 Aug 2014 05:34:33 -0400 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id s749YKQf013578; Mon, 4 Aug 2014 04:34:21 -0500 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id s749YK8C010195; Mon, 4 Aug 2014 04:34:20 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.3.174.1; Mon, 4 Aug 2014 04:34:20 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id s749YHQJ019511; Mon, 4 Aug 2014 04:34:18 -0500 Message-ID: <53DF5398.7000107@ti.com> Date: Mon, 4 Aug 2014 12:34:16 +0300 From: Roger Quadros User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Welling , Alan Stern CC: Felipe Balbi , Tony Lindgren , Alan Stern , , , , , Linux OMAP Mailing List , Linux USB Mailing List , Greg KH Subject: Re: OMAP3/AM3517 EHCI USB Issue References: <20140725200400.GB18127@sysresccd> <20140728152948.GA28880@sysresccd> <20140728155718.GF7667@saruman.home> <20140728175739.GA29212@sysresccd> <20140728181024.GI7667@saruman.home> <53D7625B.3070301@ti.com> <20140729152029.GA20542@sysresccd> <53D8B4DA.906@ti.com> <20140801230400.GA27785@sysresccd> In-Reply-To: Sender: linux-omap-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: rogerq@ti.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.180 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 08/02/2014 02:51 AM, Michael Welling wrote: > On Fri, Aug 1, 2014 at 6:04 PM, Michael Welling wrote: >> On Wed, Jul 30, 2014 at 12:03:22PM +0300, Roger Quadros wrote: >>> On 07/29/2014 06:20 PM, Michael Welling wrote: >>>> On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: >>>>> Hi Michael, >>>>> >>>>> On 07/28/2014 09:10 PM, Felipe Balbi wrote: >>>>>> On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: >>>>>>> On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: >>>>>>>>> On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: >>>>>>>>>> On Fri, 25 Jul 2014, Michael Welling wrote: >>>>>>>>>> >>>>>>>>>>> The plot thickens.... >>>>>>>>>>> >>>>>>>>>>> So if I run the above command before anything is plugged into the ports >>>>>>>>>>> the HUB disconnects. >>>>>>>>>>> >>>>>>>>>>> root@som3517:~# echo on > /sys/bus/usb/devices/1-1/power/control >>>>>>>>>>> [ 63.068839] usb 1-1: USB disconnect, device number 2 >>>>>>>>>>> >>>>>>>>>>> Here is the output of the usbmon output when running the above command: >>>>>>>>>>> root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t >>>>>>>>>>> de382e40 3788886573 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de382e40 3788890604 C Ci:001:00 0 4 = 07050000 >>>>>>>>>>> de382e40 3788892965 S Ci:001:00 s a3 00 0000 0002 0004 4 < >>>>>>>>>>> de382e40 3788893093 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de382e40 3788894834 S Ci:001:00 s a3 00 0000 0003 0004 4 < >>>>>>>>>>> de382e40 3788894958 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de7d92c0 3788896519 S Ii:001:01 -115 4 < >>>>>>>>>>> de382e40 3788898778 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de382e40 3788900188 C Ci:001:00 0 4 = 07050000 >>>>>>>>>>> de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0000 0 >>>>>>>>>>> de382e40 3788905793 C Co:001:00 0 0 >>>>>>>>>>> de382e40 3788940998 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de7d92c0 3788942065 C Ii:001:01 0 1 = 02 >>>>>>>>>>> de7d92c0 3788943013 S Ii:001:01 -115 4 < >>>>>>>>>>> de382e40 3788943145 C Ci:001:00 0 4 = 03050400 >>>>>>>>>>> de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0000 0 >>>>>>>>>>> de382e40 3788961175 C Co:001:00 0 0 >>>>>>>>>>> de382e40 3788961304 S Ci:002:00 s 80 00 0000 0000 0002 2 < >>>>>>>>>>> de382e40 3788965395 C Ci:002:00 -71 0 >>>>>>>>>>> de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0000 0 >>>>>>>>>>> de249040 3788968362 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789021103 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de7d92c0 3789022194 C Ii:001:01 0 1 = 02 >>>>>>>>>>> de7d92c0 3789022226 S Ii:001:01 -115 4 < >>>>>>>>>>> de249040 3789023423 C Ci:001:00 0 4 = 01051200 >>>>>>>>>>> de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0000 0 >>>>>>>>>>> de249040 3789026815 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789230980 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de249040 3789231111 C Ci:001:00 0 4 = 00010300 >>>>>>>>>>> de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0000 0 >>>>>>>>>>> de249040 3789232404 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0000 0 >>>>>>>>>>> de249040 3789235345 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0000 0 >>>>>>>>>>> de249040 3789237201 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0000 0 >>>>>>>>>>> de249040 3789238510 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789240602 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de249040 3789241661 C Ci:001:00 0 4 = 00010300 >>>>>>>>>>> de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0000 0 >>>>>>>>>>> de249040 3789243921 C Co:001:00 0 0 >>>>>>>>>>> de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0000 0 >>>>>>>>>>> de249040 3789246930 C Co:001:00 0 0 >>>>>>>>>>> de2490c0 3789283096 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de2490c0 3789286255 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de2490c0 3789330975 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de2490c0 3789332606 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de2490c0 3789371015 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de2490c0 3789371146 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de2490c0 3789410975 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de2490c0 3789411097 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de2490c0 3789450972 S Ci:001:00 s a3 00 0000 0001 0004 4 < >>>>>>>>>>> de2490c0 3789451081 C Ci:001:00 0 4 = 00010000 >>>>>>>>>>> de7d92c0 3789452462 C Ii:001:01 -2 0 >>>>>>>>>>> >>>>>>>>>>> Not sure what any of it means. >>>>>>>>>> >>>>>>>>>> Basically it means what you said above: the hub disconnected. I can't >>>>>>>>>> tell why. You'll have to ask someone who's familiar with the hardware >>>>>>>>>> on that board. >>>>>>>>> >>>>>>>>> Sadly, there is no one more familar with this specific hardware than myself. >>>>>>>>> >>>>>>>>> I can however ellaborate the hardware setup of the USB subsystem in >>>>>>>>> case there is someone out there that has used a similar setup. >>>>>>>>> >>>>>>>>> The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is >>>>>>>>> connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to >>>>>>>>> provide two downstream USB ports. >>>>>>>>> >>>>>>>>> The very same hardware worked with the 2.6.37 kernel that I am trying to >>>>>>>>> move away from. >>>> >>>> It should be noted that the USB hardware work on the 3.2 kernel as well. >>>> >>>>>>>>> >>>>>>>>> Today I am going to try using 3.10 and 3.14 kernels see if they exhibit >>>>>>>>> the same behavior. >>>>>>>> >>>>>>> >>>>>>> It should be noted that the 3.10 kernel did not even detect the external >>>>>>> HUB and the 3.14 kernel exhibits the same failure as 3.16. >>>>>>> >>>>>>>> Do you have off-while-idle enabled ? This could be, as Alan suggested, a >>>>>>>> problem with remote wakeup. EHCI on TI parts is kinda awkward, if you >>>>>>>> will, and getting remote wakeup with PM working, is generally a >>>>>>>> challenge. >>>>>>> >>>>>>> How would one determine if off-while-idle is enabled? Is this a flag in an >>>>>>> entry in the devicetree? >>>>>> >>>>>> there is a pm_debug file on debugfs which you can use. Set autosuspend >>>>>> delay to UART (it's set to -1 by default, IIRC), then leave the board >>>>>> idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see >>>>>> if the OFF() counters are increasing. >>>>>> >>>>>> Adding linux-omap to Cc. Also Tony, who has a simple script to enable >>>>>> pm_runtime on UART. >>>>>> >>>>> >>>>> The EHCI-omap driver when in use should prevent the USBHOST module from idling and this should in turn prevent the CORE from idling. So remote wakeup should work. It works fine in my setup with omap3beagle board OMAP3430/3530 ES3.1. >>>>> I'm using a recent u-boot v2014.07-rc4. >>>>> >>>>> It seems you are using an older silicon which needs single_ulpi_bypass flag set in platform data. >>>>> Did your below patch fix the issue for you? >>>>> https://lkml.org/lkml/2014/7/28/745 >>>> >>>> Sadly, this did not fix the issue that I am having. >>> >>> OK. what u-boot version you are on? I can try to test with the same version. >>> >>>> >>>> The problem seems to be the interaction between the PHY and the HUB on >>>> the hardware. The USB host works fine until the last device is removed >>>> from the HUB as long a device is plugged in during boot. >>> >>> OK. The ULPI link seems to be dead after the external hub and PHY suspends. >>> As 3.2 works for you it should be easy to find out what commit broke the functionality >>> for older silicon. >> >> So I found something today in our 3.2.21 kernel that probably >> worked around this suspend failure. >> >> http://git.emacinc.com/source/linux-emac.git/commit/2ede90e83c2432de5932a03dd79edd543eca1053 >> >> Sadly this means the failure predates the 3.2 kernel. >> >> So I commented out the usb_enable_autosuspend() calls in the core HUB driver and >> magically I can plug and unplug all day long without a problem. >> >> So autosuspend is causing the failure. >> >> Now what is the best way to implement a fix without trashing the kernel? > > It should be noted that the external HUB must be prevented from autosuspend > otherwise the resume fails. OK. I was able to reproduce the issue on my beagleboard as well. The key to reproduce the issue is to use a device which has autosuspend working. Earlier I was using a mass storage device so couldn't reproduce the issue. On using a HUB I could see the issue. Debugging this issue is on my action list. Meanwhile, if autosuspend is not that crucial for your application you could either disable autosuspend for the whole USB subsystem or for just that one HUB that is directly attached to the root port. To disable the autosuspend for the whole USB you need to pass "usbcore.autosuspend=-1" via the command line. This will however not disable autosuspend for HUBs. This is a bug in the kernel from v3.8 onwards. For that you need the below patch. I will send it again on the mailing list. cheers, -roger From: Roger Quadros Date: Mon, 4 Aug 2014 12:21:08 +0300 Subject: [PATCH] usb: hub: Prevent autosuspend if usbcore.autosuspend is -1 If user specifies that USB autosuspend must be disabled by module parameter "usbcore.autosuspend=-1" then we must prevent autosuspend of USB hub devices as well. commit 596d789a211d introduced in v3.8 changed the original behaivour and stopped respecting the usbcore.autosuspend parameter for hubs. Signed-off-by: Roger Quadros --- drivers/usb/core/hub.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 0e950ad..a287cd5 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1728,8 +1728,12 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) * - Change autosuspend delay of hub can avoid unnecessary auto * suspend timer for hub, also may decrease power consumption * of USB bus. + * + * - If user has indicated to prevent autosuspend by passing + * usbcore.autosuspend = -1 then keep autosuspend disabled. */ - pm_runtime_set_autosuspend_delay(&hdev->dev, 0); + if (hdev->dev.power.autosuspend_delay >= 0) + pm_runtime_set_autosuspend_delay(&hdev->dev, 0); /* * Hubs have proper suspend/resume support, except for root hubs