Hi, On 04/12/2016 09:33 AM, Felipe Balbi wrote:
I've tried latest mainline: 4.6.0-rc3+ (HEAD of github.com/torvalds/linux.git).Hi, Kirill Dronov <cyrill.dronov@xxxxxxxxx> writes:Hi Felipe, On 04/07/2016 08:10 AM, Felipe Balbi wrote:Hi, Kirill Dronov <cyrill.dronov@xxxxxxxxx> writes:I'm working on USB device bringup on Intel E3800 – based board. DWC3 core configured as DRD in device mode. The only connected device phy is SMSC 3310 (USB2 ULPI). DWC3 core version is 2.10A. Gadget zero driver can be loaded, but device enumeration fails: device is detected by host, speed is negotiated (HS), host successfully reset device. On device side – conndone interrupt is followed by linksts change with link_state 0. Then host sends USBREQ_GET_DESCRIPTOR and tries to set address but device does not react – no events generated.which kernel are you using ?It's 3.14.29 kernel (WindRiver Linux). I have backported dwc3 upstreamyou really need to ask support from WindRiver then. v3.14 is a really old kernel and even v3.14.29 is over a year old. There's very little linux-usb can do to help you. You are paying for support from WindRiver, right ? Might as well use it ;-)patches up to ~v3.17-rc4 (+ all trace patches). But the same issue exists for original 3.14.29 kernel.Please collect driver traces and send them to us: # mount -t debugfs none /sys/kernel/debug # cd /sys/kernel/debug/tracing # echo 2048 > buffer_size_kb # echo 1 > events/dwc3/enable (now trigger the problem) # cp trace /path/to/non/volatile/media/ Send that trace file (you need to compress it, probably)I've attached both dev_dbg and trace outputs. Also attached regdump taken after enumeration failed and gzero is suspended.yeah, here's the thing: DCFG = 0x00480804 This tells me that maximum-speed is set to SuperSpeed which matches the requirements to avoid the metastability problem below. This is even well commented in the source code.I'm not sure if I hit “run/stop metastability” issue [“STAR#9000525659: Clock Domain Crossing on DCTL in USB 2.0 Mode”]. I don't have DWC3we have a workaround for that, you shouldn't hit it unless you removed the workaround.No, I didn't.yeah, so you won't hit it ;-)databook or erratum description (other than mentioned in driver code). Can somebody provide more detailed description of STAR#9000525659? Where can I get DWC3 Databook?you need to talk to a Synopsys representative for that.Unfortunately Synopsis points out to Intel as SoC manufacturer and Intel share only short notes on driver configuration and loading - no Databook.right, you need to talk to your lawyer to figure out what are the requirements, nothing I can do ;-) In any case, you might wanna try latest mainline and see if you hit the problem. My bet is that you won't.
Actually the same issue with enumeration is present there (both x86 and x86_64 versions). I've attached x86_64 logs just in case. No dwc quirks or erratum enabled in probe.
Well, I see lot of dwc3_gadget_linksts_change_interrupt() but I don't know if such states sequence is correct/expected:BTW, your trace output looks really odd. Seems like you're getting a ton of spurious IRQs.
upon connection: U0 -> Rx.Detect->SS.Disabled->U0->Rx.Detect->U3 Then gadget is reset by host controller, conndone interrupt generated,then link changes U3->U0, host reports "new high-speed USB device" and tries to send USB_REQ_GET_DESCRIPTOR control message - and get error device descriptor read/64, error -71
No events generated on gadget.Then host resets gadget that leads to link change U0->Rx.Detect, reset, conndone interrupts and link change Rx.Detect->U0. And new attempt of USB_REQ_GET_DESCRIPTOR.
I have IP v.210a with both USB3_SSPHY_INTERFACE and USB3_HSPHY_INTERFACE configured (HSPHY as ULPI) but only USB2 phy attached. Can this cause such enumeration issues?
Is something definitely wrong with initialization and enumeration traces?I see that TUSB1210 was tested with Baytrail board. Are there any other known working Baytrail/phy2 combinations (my phy is smsc usb3310)? Sorry for my generic questions - more specific can be answered by Databook that I don't have.
Oh well, you really wanna talk to WindRiver through your official support channel; there's nothing this forum can do to help you, sorry.
It seems that WindRiver kernel is not guilty in this case. --- regards, Kirill
Attachment:
dwc3_trace.tgz
Description: application/compressed-tar
