From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81DBCC43144 for ; Sun, 24 Jun 2018 22:40:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3926925348 for ; Sun, 24 Jun 2018 22:40:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kLpmI0z2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3926925348 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752127AbeFXWk1 (ORCPT ); Sun, 24 Jun 2018 18:40:27 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:34087 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751625AbeFXWkY (ORCPT ); Sun, 24 Jun 2018 18:40:24 -0400 Received: by mail-it0-f68.google.com with SMTP id y127-v6so10511169itd.1; Sun, 24 Jun 2018 15:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/dmAH43kyX4umm/xRhYyqJXINAz95gfLlRxOCncoMkg=; b=kLpmI0z2TCJWRI09ltCrLDLp3vgMsuiw/WP3aPZFPZ1n+KwReQjXHpTmaapEKg7HjH bu9J2komdWTxPsLpiphDKBiZ9JW3zpmbXVsR1tH+1zF7+HbUU4qRoVmim9ekMecHy8Tv p8OlK27FW9r5QJxXeY0sPS7+WKaw1v9WTQMiKVkMmP2jg4YjtPpp9o1hSh8tGOg3Wn45 /mzIlZCvBSTp0ROiMDaPwPc66KUMgI8NbbR5AAujW4gY6HLsoJ8pM8spygDNzVpWseOb hCFxJ09552opR/PdFD+ZkhVreaK1Jc9VCFOsrpQ7aGmYJo8ignzufdYCsmyCIvu3b/Ht soSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/dmAH43kyX4umm/xRhYyqJXINAz95gfLlRxOCncoMkg=; b=m8XveFu+qrwT7l+7FWFuEnfDS0t97A5tBTn4dGQHOgiIpPMpzhTvTRvIk4xxJ3b+wM zvSc3ELHMLOpX/MBX54U7PYGeURoqsTmv7U5Tk/WtaFBbn+bo8aX9esV3rn703v7kEKO Yyeqsz2F/iWXGc0adM1YMO3sVve1hSdg4KNlTOd5P0+/tuZ91lJ45I/H3wFMlytV4xES IotKq8fwQKcXi1aqUwQvg5+YkmcVz1+siU+Jtn2cmZcTeNpThSL5IyGWoFBDhSphKCzS Wu8MIQLRLLgEQxyb2GHaY9xhxh4YaHXymdLpo29t7q7OT15evDYlHVFjiDBxnbTFUnk5 XZeg== X-Gm-Message-State: APt69E2ZvWfhvNPruvOxtWklRja04WB+Zu5K9XruJh1za74rjHRGvpv1 BzHhUevGTIfdfnm8/ly9dIfx68HqUoyWDVVoYbdbhTgv X-Google-Smtp-Source: ADUXVKItmvFHsrcn1ewpDukkFzt3iOahy1U1CmctzWLzpJLfs1wzTgkY24bpn5buuZyhAaxp9Dqpp/aEBbR7xjr9u1Y= X-Received: by 2002:a24:a501:: with SMTP id k1-v6mr8037223itf.79.1529880023075; Sun, 24 Jun 2018 15:40:23 -0700 (PDT) MIME-Version: 1.0 References: <20180530173414.6121-1-andrew.smirnov@gmail.com> In-Reply-To: From: Andrey Smirnov Date: Sun, 24 Jun 2018 15:40:11 -0700 Message-ID: Subject: Re: [PATCH] usb: chipidea: Fix ULPI on imx51 To: Fabio Estevam Cc: Greg Kroah-Hartman , Nikita Yushchenko , Peter Chen , linux-usb@vger.kernel.org, linux-kernel , linux-arm-kernel , Fabio Estevam , Chris Healy , Lucas Stach , Sebastian Reichel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam wrote: > > Hi Andrey, > > On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov > wrote: > > > I just finished experimenting with it on RDU1 and Babbage boards and I > > can't reproduce the hang that you describe against 4.18-rc1. At this > > point I wonder if it's the bootloader that is a variable that plays > > into this. I was booting both boards with 2018.06.0 version of barebox > > + the custom patches that can be found here > > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the > > last patch in that branch/stack was added as a part of this > > investigation, but even before it, I was able to boot Linux just fine, > > albeit without working USB. > > Thanks for investigating this issue. > > Yes, t is possible that the difference in behaviour that we see could > be related to the fact we use different bootloaders. > > In order to make things easier, I am sharing a Buildroot image for > imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2: > https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0 > > Please flash it directly to the SD card via dd and boot it. > > You will notice that it will boot normally. Then please copy a > 4.18-rc1 zImage into the first SD card partition and you will notice > the hang. > It's definitely the bootloader, or more specifically whether or not it initialized/used USB before booting the kernel. Some interesting highlights: - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb start" (optionally "usb stop") and then "boot", you'll get the hang that I was trying to fix with my patch. - Things are exact opposite with 4.18-rc1 and doing the above would _prevent_ the hang and the image would boot fine. - Disabling USB in Barebox based boot "stack" gets it to behave the same way as U-boot from your image (hanging when booting 4.18-rc1) Digging more into code it seems that the reason for 4.18-rc1's behavior is the fact that it's missing a call hw_phymode_configure() after usb_phy_init() and, AFAICT, the only reason it is not happening is because default image is being built without CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two options on 4.18-rc1, seem to fix the problem on both your U-Boot based image and my "special" Barebox setup. So AFAICT, this patch still fixes a valid issue (my use-case was net booting via USB-Ethernet dongle), but an additional patch enabling those two configuration options might be needed. Thoughts? Also, I don't have any i.MX53 HW, so I wasn't able to test the effects of enabling those two options there. Thanks, Andrey Smirnov From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Subject: usb: chipidea: Fix ULPI on imx51 From: Andrey Smirnov Message-Id: Date: Sun, 24 Jun 2018 15:40:11 -0700 To: Fabio Estevam Cc: Greg Kroah-Hartman , Nikita Yushchenko , Peter Chen , linux-usb@vger.kernel.org, linux-kernel , linux-arm-kernel , Fabio Estevam , Chris Healy , Lucas Stach , Sebastian Reichel List-ID: T24gRnJpLCBKdW4gMjIsIDIwMTggYXQgOToyNyBBTSBGYWJpbyBFc3RldmFtIDxmZXN0ZXZhbUBn bWFpbC5jb20+IHdyb3RlOgo+Cj4gSGkgQW5kcmV5LAo+Cj4gT24gVGh1LCBKdW4gMjEsIDIwMTgg YXQgNjo0NCBQTSwgQW5kcmV5IFNtaXJub3YKPiA8YW5kcmV3LnNtaXJub3ZAZ21haWwuY29tPiB3 cm90ZToKPgo+ID4gSSBqdXN0IGZpbmlzaGVkIGV4cGVyaW1lbnRpbmcgd2l0aCBpdCBvbiBSRFUx IGFuZCBCYWJiYWdlIGJvYXJkcyBhbmQgSQo+ID4gY2FuJ3QgcmVwcm9kdWNlIHRoZSBoYW5nIHRo YXQgeW91IGRlc2NyaWJlIGFnYWluc3QgNC4xOC1yYzEuIEF0IHRoaXMKPiA+IHBvaW50IEkgd29u ZGVyIGlmIGl0J3MgdGhlIGJvb3Rsb2FkZXIgdGhhdCBpcyBhIHZhcmlhYmxlIHRoYXQgcGxheXMK PiA+IGludG8gdGhpcy4gSSB3YXMgYm9vdGluZyBib3RoIGJvYXJkcyB3aXRoIDIwMTguMDYuMCB2 ZXJzaW9uIG9mIGJhcmVib3gKPiA+ICsgdGhlIGN1c3RvbSBwYXRjaGVzIHRoYXQgY2FuIGJlIGZv dW5kIGhlcmUKPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9uZHJleXMvYmFyZWJveC9jb21taXRzL3Jk dTEtbmV0Ym9vdC4gTm90ZSB0aGF0IHRoZQo+ID4gbGFzdCBwYXRjaCBpbiB0aGF0IGJyYW5jaC9z dGFjayB3YXMgYWRkZWQgYXMgYSBwYXJ0IG9mIHRoaXMKPiA+IGludmVzdGlnYXRpb24sIGJ1dCBl dmVuIGJlZm9yZSBpdCwgSSB3YXMgYWJsZSB0byBib290IExpbnV4IGp1c3QgZmluZSwKPiA+IGFs YmVpdCB3aXRob3V0IHdvcmtpbmcgVVNCLgo+Cj4gVGhhbmtzIGZvciBpbnZlc3RpZ2F0aW5nIHRo aXMgaXNzdWUuCj4KPiBZZXMsIHQgaXMgcG9zc2libGUgdGhhdCB0aGUgZGlmZmVyZW5jZSBpbiBi ZWhhdmlvdXIgdGhhdCB3ZSBzZWUgY291bGQKPiBiZSByZWxhdGVkIHRvIHRoZSBmYWN0IHdlIHVz ZSBkaWZmZXJlbnQgYm9vdGxvYWRlcnMuCj4KPiBJbiBvcmRlciB0byBtYWtlIHRoaW5ncyBlYXNp ZXIsIEkgYW0gc2hhcmluZyBhIEJ1aWxkcm9vdCBpbWFnZSBmb3IKPiBpbXg1MS1iYWJiYWdlIHRo YXQgY29udGFpbnMgVS1Cb290IDIwMTguMDUgKyBrZXJuZWwgNC4xNy4yOgo+IGh0dHBzOi8vd3d3 LmRyb3Bib3guY29tL3MveWV2bnU0eTF6ZGNobmJ0L3NkY2FyZC5pbWc/ZGw9MAo+Cj4gUGxlYXNl IGZsYXNoIGl0IGRpcmVjdGx5IHRvIHRoZSBTRCBjYXJkIHZpYSBkZCBhbmQgYm9vdCBpdC4KPgo+ IFlvdSB3aWxsIG5vdGljZSB0aGF0IGl0IHdpbGwgYm9vdCBub3JtYWxseS4gVGhlbiBwbGVhc2Ug Y29weSBhCj4gNC4xOC1yYzEgekltYWdlIGludG8gdGhlIGZpcnN0IFNEIGNhcmQgcGFydGl0aW9u IGFuZCB5b3Ugd2lsbCBub3RpY2UKPiB0aGUgaGFuZy4KPgoKSXQncyBkZWZpbml0ZWx5IHRoZSBi b290bG9hZGVyLCBvciBtb3JlIHNwZWNpZmljYWxseSB3aGV0aGVyIG9yIG5vdCBpdAppbml0aWFs aXplZC91c2VkIFVTQiBiZWZvcmUgYm9vdGluZyB0aGUga2VybmVsLiBTb21lIGludGVyZXN0aW5n CmhpZ2hsaWdodHM6CgogLSBPbiB5b3VyICJnb29kIiA0LjE3LjIgYmFzZWQgaW1hZ2UsIGlmIHlv dSBpbnRlcnJ1cHQgVS1Cb290LCBkbyAidXNiCnN0YXJ0IiAob3B0aW9uYWxseSAidXNiIHN0b3Ai KSBhbmQgdGhlbiAiYm9vdCIsIHlvdSdsbCBnZXQgdGhlIGhhbmcKdGhhdCBJIHdhcyB0cnlpbmcg dG8gZml4IHdpdGggbXkgcGF0Y2guCgogLSBUaGluZ3MgYXJlIGV4YWN0IG9wcG9zaXRlIHdpdGgg NC4xOC1yYzEgYW5kIGRvaW5nIHRoZSBhYm92ZSB3b3VsZApfcHJldmVudF8gdGhlIGhhbmcgYW5k IHRoZSBpbWFnZSB3b3VsZCBib290IGZpbmUuCgogLSBEaXNhYmxpbmcgVVNCIGluIEJhcmVib3gg YmFzZWQgYm9vdCAic3RhY2siIGdldHMgaXQgdG8gYmVoYXZlIHRoZQpzYW1lIHdheSBhcyBVLWJv b3QgZnJvbSB5b3VyIGltYWdlIChoYW5naW5nIHdoZW4gYm9vdGluZyA0LjE4LXJjMSkKCkRpZ2dp bmcgbW9yZSBpbnRvIGNvZGUgaXQgc2VlbXMgdGhhdCB0aGUgcmVhc29uIGZvciA0LjE4LXJjMSdz CmJlaGF2aW9yIGlzIHRoZSBmYWN0IHRoYXQgaXQncyBtaXNzaW5nIGEgY2FsbCBod19waHltb2Rl X2NvbmZpZ3VyZSgpCmFmdGVyIHVzYl9waHlfaW5pdCgpIGFuZCwgQUZBSUNULCB0aGUgb25seSBy ZWFzb24gaXQgaXMgbm90IGhhcHBlbmluZwppcyBiZWNhdXNlIGRlZmF1bHQgaW1hZ2UgaXMgYmVp bmcgYnVpbHQgd2l0aG91dApDT05GSUdfVVNCX0NISVBJREVBX1VMUEkgYW5kIENPTkZJR19VU0Jf VUxQSV9CVVMuIEVuYWJsaW5nIHRob3NlIHR3bwpvcHRpb25zIG9uIDQuMTgtcmMxLCBzZWVtIHRv IGZpeCB0aGUgcHJvYmxlbSBvbiBib3RoIHlvdXIgVS1Cb290IGJhc2VkCmltYWdlIGFuZCBteSAi c3BlY2lhbCIgQmFyZWJveCBzZXR1cC4KClNvIEFGQUlDVCwgdGhpcyBwYXRjaCBzdGlsbCBmaXhl cyBhIHZhbGlkIGlzc3VlIChteSB1c2UtY2FzZSB3YXMgbmV0CmJvb3RpbmcgdmlhIFVTQi1FdGhl cm5ldCBkb25nbGUpLCBidXQgYW4gYWRkaXRpb25hbCBwYXRjaCBlbmFibGluZwp0aG9zZSB0d28g Y29uZmlndXJhdGlvbiBvcHRpb25zIG1pZ2h0IGJlIG5lZWRlZC4gVGhvdWdodHM/CgpBbHNvLCBJ IGRvbid0IGhhdmUgYW55IGkuTVg1MyBIVywgc28gSSB3YXNuJ3QgYWJsZSB0byB0ZXN0IHRoZSBl ZmZlY3RzCm9mIGVuYWJsaW5nIHRob3NlIHR3byBvcHRpb25zIHRoZXJlLgoKVGhhbmtzLApBbmRy ZXkgU21pcm5vdgotLS0KVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp bmUgInVuc3Vic2NyaWJlIGxpbnV4LXVzYiIgaW4KdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1h am9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcKTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0cDovL3Zn ZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: andrew.smirnov@gmail.com (Andrey Smirnov) Date: Sun, 24 Jun 2018 15:40:11 -0700 Subject: [PATCH] usb: chipidea: Fix ULPI on imx51 In-Reply-To: References: <20180530173414.6121-1-andrew.smirnov@gmail.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jun 22, 2018 at 9:27 AM Fabio Estevam wrote: > > Hi Andrey, > > On Thu, Jun 21, 2018 at 6:44 PM, Andrey Smirnov > wrote: > > > I just finished experimenting with it on RDU1 and Babbage boards and I > > can't reproduce the hang that you describe against 4.18-rc1. At this > > point I wonder if it's the bootloader that is a variable that plays > > into this. I was booting both boards with 2018.06.0 version of barebox > > + the custom patches that can be found here > > https://github.com/ndreys/barebox/commits/rdu1-netboot. Note that the > > last patch in that branch/stack was added as a part of this > > investigation, but even before it, I was able to boot Linux just fine, > > albeit without working USB. > > Thanks for investigating this issue. > > Yes, t is possible that the difference in behaviour that we see could > be related to the fact we use different bootloaders. > > In order to make things easier, I am sharing a Buildroot image for > imx51-babbage that contains U-Boot 2018.05 + kernel 4.17.2: > https://www.dropbox.com/s/yevnu4y1zdchnbt/sdcard.img?dl=0 > > Please flash it directly to the SD card via dd and boot it. > > You will notice that it will boot normally. Then please copy a > 4.18-rc1 zImage into the first SD card partition and you will notice > the hang. > It's definitely the bootloader, or more specifically whether or not it initialized/used USB before booting the kernel. Some interesting highlights: - On your "good" 4.17.2 based image, if you interrupt U-Boot, do "usb start" (optionally "usb stop") and then "boot", you'll get the hang that I was trying to fix with my patch. - Things are exact opposite with 4.18-rc1 and doing the above would _prevent_ the hang and the image would boot fine. - Disabling USB in Barebox based boot "stack" gets it to behave the same way as U-boot from your image (hanging when booting 4.18-rc1) Digging more into code it seems that the reason for 4.18-rc1's behavior is the fact that it's missing a call hw_phymode_configure() after usb_phy_init() and, AFAICT, the only reason it is not happening is because default image is being built without CONFIG_USB_CHIPIDEA_ULPI and CONFIG_USB_ULPI_BUS. Enabling those two options on 4.18-rc1, seem to fix the problem on both your U-Boot based image and my "special" Barebox setup. So AFAICT, this patch still fixes a valid issue (my use-case was net booting via USB-Ethernet dongle), but an additional patch enabling those two configuration options might be needed. Thoughts? Also, I don't have any i.MX53 HW, so I wasn't able to test the effects of enabling those two options there. Thanks, Andrey Smirnov