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: Use device tree to disable U1/U2 in gadget devices based on DWC3 From: "Claus H. Stovgaard" Message-Id: <1556284501.6914.55.camel@phaseone.com> Date: Fri, 26 Apr 2019 15:15:01 +0200 To: Rob Weber , Alan Stern Cc: "balbi@kernel.org" , "linux-usb@vger.kernel.org" , "mnarani@xilinx.com" , Michal Simek List-ID: T24gVGh1LCAyMDE5LTA0LTI1IGF0IDEzOjExIC0wNzAwLCBSb2IgV2ViZXIgd3JvdGU6Cj4gSGkg RXZlcnlvbmUsCj4gCj4gT24gV2VkLCBBcHIgMjQsIDIwMTkgYXQgMDI6MzM6NDhQTSAtMDQwMCwg QWxhbiBTdGVybiB3cm90ZToKPiA+IAo+ID4gT24gV2VkLCAyNCBBcHIgMjAxOSwgQ2xhdXMgSC4g U3RvdmdhYXJkIHdyb3RlOgo+ID4gCj4gPiA+IAo+ID4gPiBIaSBCYWxiaSBhbmQgb3RoZXIgVVNC IGRldmVsb3BlcnMuCj4gPiA+IAo+ID4gPiBJIGFtIGRldmVsb3BpbmcgY2FtZXJhIGRldmljZXMg YmFzZWQgb24gWGlsaW54IFp5bnFNUCwgdXNpbmcgdGhlCj4gPiA+IGdhZGdldCBmcmFtZXdvcmsg YW5kIHRoZSBidWlsZC1pbiBkd2MzIGNvcmUgb2YgdGhlIFp5bnFNUCBhcyBVU0IzCj4gPiA+IGNv bnRyb2xsZXIgYW5kIHRoZSBidWlsZC1pbiBDaXJydXMgU0VSREVTIGFzIHBoeS4KPiA+ID4gVGVz dGluZyB3aXRoIGEgbnVtYmVyIG9mIGhvc3RzIGFuZCBXaW5kb3dzIDcsIGhhcyBzaG93biBzcG9y YWRpYwo+ID4gPiByZWNvbm5lY3RzIHdoZW4gbGVhdmluZyBVMi9VMSwgY2F1c2VkIGJ5IGZhaWxp bmcgbGluayB0cmFpbmluZywKPiA+ID4gd2hlcmUKPiA+ID4gdGhlIGhvc3QgcmVzZXRzIHRoZSBi dXMuIFNvbWV0aW1lIGl0IGFsc28gbWVhbnMgaXQgcmVjb25uZWN0IHZpYQo+ID4gPiBVU0IyLgo+ ID4gPiAKPiA+ID4gU28gdG8gb3ZlcmNvbWUgdGhpcywgSSB3aWxsIGxpa2UgdG8gaGF2ZSB0aGUg b3B0aW9uIGZvciBkaXNhYmxpbmcKPiA+ID4gVTEvVTIgb24gdGhlIGNvcmUgd2hlbiB3b3JraW5n IHdpdGggdGhvc2UgaG9zdHMuCj4gPiA+IAo+ID4gPiBDdXJyZW50bHkgSSBoYXZlIG1hZGUgYSBo YWNrIGluIGVwMC5jIHdoZXJlIEkgcmV0dXJuIEVJTlZBTCBpbgo+ID4gPiBkd2MzX2VwMF9oYW5k bGVfdTEgYW5kIGR3YzNfZXAwX2hhbmRsZV91MiB0b2dldGhlciB3aXRoIG5vdAo+ID4gPiBzZXR0 aW5nCj4gPiA+IERXQzNfRENUTF9BQ0NFUFRVMUVOQSBhbmQgRFdDM19EQ1RMX0FDQ0VQVFUyRU5B IGluCj4gPiA+IGR3YzNfZXAwX3NldF9jb25maWcKPiA+ID4gV2lsbCB0aG91Z2ggcHJlZmVyIGEg c29sdXRpb24gcG9zc2libGUgdG8gdXBzdHJlYW0sIHNvIHdhcwo+ID4gPiB0aGlua2luZwo+ID4g PiBhYm91dCBhZGRpbmcgdHdvIGRldmljZXRyZWUgYmluZGluZ3MuCj4gPiA+IAo+ID4gPiAqIHNu cHMsdTFfZGlzYWJsZV9hc19nYWRnZXQ6IFdoZW4gc2V0IHRoZSBjb3JlIHdpbGwgbm90IGVuYWJs ZSBVMQo+ID4gPiBpZgo+ID4gPiByZXF1ZXN0ZWQgZnJvbSBob3N0LCBub3IgaW5pdGlhdGUgVTEu Cj4gPiA+ICogc25wcyx1Ml9kaXNhYmxlX2FzX2dhZGdldDogV2hlbiBzZXQgdGhlIGNvcmUgd2ls bCBub3QgZW5hYmxlIFUyCj4gPiA+IGlmCj4gPiA+IHJlcXVlc3RlZCBmcm9tIGhvc3QsIG5vciBp bml0aWF0ZSBVMi4KPiA+ID4gCj4gPiA+IElmIHlvdSB0aGluayB0aGlzIG1pZ2h0IGJlIHNvbWV0 aGluZyB3aGljaCBjYW4gYmUgdXBzdHJlYW1lZCBJCj4gPiA+IHdpbGwKPiA+ID4gcHJlcGFyZSB0 aGUgY29kZSBhbmQgc2VuZCBhIHBhdGNoIGZvciBkaXNjdXNzaW9uLgo+ID4gPiBPbiB0aGUgb3Ro ZXIgaGFuZCwgaWYgeW91IHRoaW5rIHRoYXQgZGlzYWJsaW5nIFUxL1UyIHZpYSBkZXZpY2UKPiA+ ID4gdHJlZQo+ID4gPiBhcyBzdWdnZXN0ZWQgc2hvdWxkIG5vdCBiZSBhIGZlYXR1cmUgbm8gbmVl ZCBmb3IgbWUgdG8gdHJ5IG1ha2luZwo+ID4gPiBpdAo+ID4gPiBhIGZlYXR1cmUuCj4gPiBTcGVh a2luZyBhcyBhbiBpbnRlcmVzdGVkIGJ5c3RhbmRlciwgSSB3b3VsZCBmaXJzdCB3b25kZXIgd2h5 IHlvdXIKPiA+IGhhcmR3YXJlIGZhaWxzIGR1cmluZyBsaW5rIHRyYWluaW5nLsKgwqBJZiBpdCBp cyBwcm9wZXJseSBkZXNpZ25lZCwKPiA+IHRoYXQKPiA+IHNob3VsZCBub3QgaGFwcGVuLsKgwqBU aGUgZmFjdCB0aGF0IGl0IGRvZXMgaGFwcGVuIHN1Z2dlc3RzIHlvdXIKPiA+IGRldmljZXMKPiA+ IG1pZ2h0IGFsc28gZXhwZXJpZW5jZSBwcm9ibGVtcyBkdXJpbmcgbm9ybWFsIGRhdGEgdHJhbnNw b3J0Lgo+IEkgd2FzIHJlY2VudGx5IGRlYnVnZ2luZyBhIHNpbWlsYXIgcHJvYmxlbSB3aGVyZSBt eSBkZXZpY2Ugd291bGQKPiBpbXByb3Blcmx5IHRyYW5zaXRpb24gZnJvbSBVMiB0byBVMC4gVGhp cyBjYXVzZWQgdGhlIGNvbm5lY3Rpb24gdG8KPiByZXNldAo+IGFuZCB0aGUgZGV2aWNlIHRvIGJl IHJlLWVudW1lcmF0ZWQgYXMgYSBVU0IyIGRldmljZS4gT3VyIGRlc2lnbiB1c2VzCj4gYW4KPiBJ bnRlbCBDaGVycnlUcmFpbCB6ODU1MCBTb0MgdGhhdCBoYXMgYW4gaW50ZXJuYWwgZHdjMyBVU0Ig ZGV2aWNlCj4gY29udHJvbGxlci4gSSB3b3JrZWQgd2l0aCBGZWxpcGUgYSBjb3VwbGUgb2Ygd2Vl a3MgYWdvIFsxXSB0byBjb21lIHVwCj4gd2l0aAo+IHRoZSBzYW1lIHdvcmthcm91bmQgeW91IG1l bnRpb25lZCBhYm92ZS4gSSBkaXNhYmxlIGRldmljZS1pbml0aWF0ZWQKPiBVMS9VMgo+IGluIGVw MF9zZXRfY29uZmlnIGFuZCBhbHNvIHJldHVybiAtRUlOVkFMIHdoZW4gaGFuZGxpbmcgU2V0RmVh dHVyZQo+IHJlcXVlc3RzIGZyb20gdGhlIFVTQiBob3N0LiBJJ3ZlIGF0dGFjaGVkIG15IHBhdGNo IGZvciBrZXJuZWwgNC45LjExNQo+IGJlbG93IGZvciByZWZlcmVuY2UuCj4gCj4gQWx0aG91Z2gg d2UgaGF2ZSBhcHBsaWVkIHRoaXMgd29ya2Fyb3VuZCwgd2Ugc3RpbGwgaGF2ZSBub3QKPiBpZGVu dGlmaWVkIGEKPiByb290IGNhdXNlIG9mIHRoZSBpc3N1ZS4gSW50ZWwgaGFzIG5vIGtub3duIGVy cmF0YSByZWxhdGVkIHRvIHRoZQo+IHN5bXB0b21zCj4gd2UgYXJlIGV4cGVyaWVuY2luZy4gV2Un dmUgZG9uZSBxdWl0ZSBhIGJpdCBvZiBhbmFseXNpcyBvbiBvdXIgZGVzaWduCj4gYW5kCj4gYXJl IHByZXR0eSBjb25maWRlbnQgd2UndmUgZm9sbG93ZWQgYWxsIGRlc2lnbiBndWlkZWxpbmVzIGZv ciBVU0IuCj4gCj4gQ2hlZXJzLAo+IFJvYiBXZWJlcgo+IAo+IFsxXSBodHRwczovL21hcmMuaW5m by8/dD0xNTUzNDk5MzU2MDAwMDEmcj0xJnc9MgoKVGhhbmtzIGZvciB0aGlzIGluZm8sIHJlYWRp bmcgdGhyb3VnaCB5b3VyIHRocmVhZCBhbmQgY2FuIHNlZSBtYW55CnNpbWlsYXJpdGllcy4KRllJ IHdlIGFyZSBhbHNvIHVzaW5nIGEgVHlwZS1DIGludGVyZmFjZSAoVXNpbmcgdGhlIEN5cHJlc3Mg Q0NHNCBhcwpjb250cm9sbGVyKSwgYW5kIHVzaW5nIGEgcmVkcml2ZXIgLyBtdXguIFdlIGFyZSB1 c2luZyB0aGXCoHR1c2IxMDQyaQoKSGF2ZSBwcmV2aW91c2x5IGFza2VkIGZvciBpbmZvcm1hdGlv biBmcm9tIFhpbGlueCBmb3IgdGhlIGR3YzMgY29yZQoodGhlIHN5bm9wc3lzIGRvY3VtZW50YXRp b24pLCBhbmQgaW5mbyByZWdhcmRpbmcgdGhlIFBIWS4gVGhlIHNlcmRlcwptb2R1bGUgdXNlZCBh cyBwaHkgaXMgcHJldHR5IHVuZG9jdW1lbnRlZCBpbiB0aGUgWGlsaW54IGRvY3VtZW50YXRpb24s CndpdGggbWFueSByZWdpc3RlcnMgbGVmdCB1bmRvY3VtZW50ZWQuCgpQbGVhc2Uga2VlcCBtZSBw b3N0ZWQgaWYgeW91IGZpbmQgdGhlIHJvb3QgY2F1c2UgZm9yIHlvdXIgcHJvYmxlbSwgYW5kCkkg d2lsbCBkbyB0aGUgc2FtZS4KCi9DbGF1cwo= 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.9 required=3.0 tests=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 E7704C43218 for ; Fri, 26 Apr 2019 13:15:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB5FF2077B for ; Fri, 26 Apr 2019 13:15:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726120AbfDZNPG (ORCPT ); Fri, 26 Apr 2019 09:15:06 -0400 Received: from mail1.bemta25.messagelabs.com ([195.245.230.132]:51383 "EHLO mail1.bemta25.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726013AbfDZNPG (ORCPT ); Fri, 26 Apr 2019 09:15:06 -0400 Received: from [46.226.53.55] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-c.eu-west-1.aws.symcld.net id 44/83-09106-75403CC5; Fri, 26 Apr 2019 13:15:03 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRWlGSWpSXmKPExsUyo1hfUjec5XC Mwdc/jBbH2p6wWyxa1sps8e5lhMXcfW9ZLC6u38loMeH3BTYHNo+upmZ2j02rOtk8Zt/9wejx eZOcx97Pv1kCWKNYM/OS8isSWDMmf5nKWrBQpuLm32esDYyXxboYuTiEBNYySqxds5uxi5GTg 1fAWOJrywKmLkYODmEBX4npFxJATDYBXYmuO6YgFSIC7hJ/Zx1mBGllFtjOKLG85SAbSIJFQF Xi07a5YDangLbE9GUzWCHmH2WU+PBhFth8ZgFNidbtv9lBbAkBDYkNN48xQewVlDg58wkLRI2 8RPPW2cwgi4UEZCWOXoqFKFeQOLtlIiOEnSRxrKmRcQKjwCwkU2chmTQLyaQFjMyrGM2SijLT M0pyEzNzdA0NDHQNDY10jQwMdY31Eqt0k/VSS3XLU4tLdA31EsuL9Yorc5NzUvTyUks2MQLjI aXgJPMOxmcr0g8xSnIwKYny1n86FCPEl5SfUpmRWJwRX1Sak1p8iFGGg0NJgreX+XCMkGBRan pqRVpmDjAyYdISHDxKIrxXQdK8xQWJucWZ6RCpU4y6HDNnPp/LLMSSl5+XKiXOuxmkSACkKKM 0D24ELElcYpSVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMex1kCk9mXgncpldARzABHZGy8hDI ESWJCCmpBsa9SxZLcdX+Xbejf1bYFRcV6cNPtvHw8ajG/RA9qNLY4y6+4+mbGPEbv3JsxXvOp GtOf7i/WFaoM+Dh5jPW5cvP2oawVux21O/ZMuXfgZUT4wVLpf9cNbG5qbz2g8OR6ITcqMN+oU Irwjd7fMvluMUTzNn+k2+WkejE46y715ypndj2x0g3crkSS3FGoqEWc1FxIgDte3ZTDQMAAA= = X-Env-Sender: cst@phaseone.com X-Msg-Ref: server-12.tower-307.messagelabs.com!1556284502!6678856!1 X-Originating-IP: [152.115.47.25] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13687 invoked from network); 26 Apr 2019 13:15:02 -0000 Received: from unknown (HELO Exchange2.phaseone.com) (152.115.47.25) by server-12.tower-307.messagelabs.com with AES256-SHA encrypted SMTP; 26 Apr 2019 13:15:02 -0000 Received: from cstu16.phaseone.com (172.16.2.207) by Exchange2.phaseone.com (172.16.1.180) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 15:15:00 +0200 Message-ID: <1556284501.6914.55.camel@phaseone.com> Subject: Re: Use device tree to disable U1/U2 in gadget devices based on DWC3 From: "Claus H. Stovgaard" To: Rob Weber , Alan Stern CC: "balbi@kernel.org" , "linux-usb@vger.kernel.org" , "mnarani@xilinx.com" , Michal Simek Date: Fri, 26 Apr 2019 15:15:01 +0200 In-Reply-To: <20190425201103.GA26402@coops> References: <20190425201103.GA26402@coops> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [172.16.2.207] X-ClientProxiedBy: Exchange2.phaseone.com (172.16.1.180) To Exchange2.phaseone.com (172.16.1.180) Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Message-ID: <20190426131501.BaHATuMCQWYrTY27_aYdj20DItd-vc1LEpFvOB8KdYE@z> On Thu, 2019-04-25 at 13:11 -0700, Rob Weber wrote: > Hi Everyone, > > On Wed, Apr 24, 2019 at 02:33:48PM -0400, Alan Stern wrote: > > > > On Wed, 24 Apr 2019, Claus H. Stovgaard wrote: > > > > > > > > Hi Balbi and other USB developers. > > > > > > I am developing camera devices based on Xilinx ZynqMP, using the > > > gadget framework and the build-in dwc3 core of the ZynqMP as USB3 > > > controller and the build-in Cirrus SERDES as phy. > > > Testing with a number of hosts and Windows 7, has shown sporadic > > > reconnects when leaving U2/U1, caused by failing link training, > > > where > > > the host resets the bus. Sometime it also means it reconnect via > > > USB2. > > > > > > So to overcome this, I will like to have the option for disabling > > > U1/U2 on the core when working with those hosts. > > > > > > Currently I have made a hack in ep0.c where I return EINVAL in > > > dwc3_ep0_handle_u1 and dwc3_ep0_handle_u2 together with not > > > setting > > > DWC3_DCTL_ACCEPTU1ENA and DWC3_DCTL_ACCEPTU2ENA in > > > dwc3_ep0_set_config > > > Will though prefer a solution possible to upstream, so was > > > thinking > > > about adding two devicetree bindings. > > > > > > * snps,u1_disable_as_gadget: When set the core will not enable U1 > > > if > > > requested from host, nor initiate U1. > > > * snps,u2_disable_as_gadget: When set the core will not enable U2 > > > if > > > requested from host, nor initiate U2. > > > > > > If you think this might be something which can be upstreamed I > > > will > > > prepare the code and send a patch for discussion. > > > On the other hand, if you think that disabling U1/U2 via device > > > tree > > > as suggested should not be a feature no need for me to try making > > > it > > > a feature. > > Speaking as an interested bystander, I would first wonder why your > > hardware fails during link training.  If it is properly designed, > > that > > should not happen.  The fact that it does happen suggests your > > devices > > might also experience problems during normal data transport. > I was recently debugging a similar problem where my device would > improperly transition from U2 to U0. This caused the connection to > reset > and the device to be re-enumerated as a USB2 device. Our design uses > an > Intel CherryTrail z8550 SoC that has an internal dwc3 USB device > controller. I worked with Felipe a couple of weeks ago [1] to come up > with > the same workaround you mentioned above. I disable device-initiated > U1/U2 > in ep0_set_config and also return -EINVAL when handling SetFeature > requests from the USB host. I've attached my patch for kernel 4.9.115 > below for reference. > > Although we have applied this workaround, we still have not > identified a > root cause of the issue. Intel has no known errata related to the > symptoms > we are experiencing. We've done quite a bit of analysis on our design > and > are pretty confident we've followed all design guidelines for USB. > > Cheers, > Rob Weber > > [1] https://marc.info/?t=155349935600001&r=1&w=2 Thanks for this info, reading through your thread and can see many similarities. FYI we are also using a Type-C interface (Using the Cypress CCG4 as controller), and using a redriver / mux. We are using the tusb1042i Have previously asked for information from Xilinx for the dwc3 core (the synopsys documentation), and info regarding the PHY. The serdes module used as phy is pretty undocumented in the Xilinx documentation, with many registers left undocumented. Please keep me posted if you find the root cause for your problem, and I will do the same. /Claus