Hi, Kirill Dronov <cyrill.dronov@xxxxxxxxx> writes: >>>> > irq/19-dwc3-96 [000] d..2 825.229265: dwc3_event: event 00000301 >>> Link change U3 [3] -> U0 [0] >>> Host reports: " new high-speed USB device number XX using ehci-pci" >>> Host Sends USB_REQ_GET_DESCRIPTOR 3 times, gets r=-71. No events >>> detected on dwc3 side - this is the root issue. >>> >>> Then host initiates device reset. >>>> > irq/19-dwc3-96 [000] d..2 825.322544: dwc3_event: event 00050301 >>> Link state change U0[0] -> Rx.Detect [5] >>>> > irq/19-dwc3-96 [000] d..2 825.323162: dwc3_event: event 00000101 >>> Reset interrupt >>>> > irq/19-dwc3-96 [000] d..2 825.329773: dwc3_event: event 00000201 >>> Conndone interrupt >>>> > irq/19-dwc3-96 [000] d..2 825.329777: dwc3_gadget: Enabling ep0out >>>> > irq/19-dwc3-96 [000] d..2 825.329782: dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [1] params 80000200 00000500 00000000 >>>> > irq/19-dwc3-96 [000] d..2 825.329786: dwc3_gadget: Command Complete --> 0 >>>> > irq/19-dwc3-96 [000] d..2 825.329788: dwc3_gadget: Enabling ep0in >>>> > irq/19-dwc3-96 [000] d..2 825.329789: dwc3_gadget_ep_cmd: ep0in: cmd 'Set Endpoint Configuration' [1] params 80000200 02000500 00000000 >>>> > irq/19-dwc3-96 [000] d..2 825.329793: dwc3_gadget: Command Complete --> 0 >>>> >>>> All over again. And this repeats forever. >>> Well, actually it follows host enumeration process - with >>> usb_contorl_msg and hub_set_address returning -71, >>> and hub-initiated reset resulting in following sequence: >>> Link U0->Rx.Detect >>> reset interrupt >>> conndone interrupt >>> Link Rx.Detect -> U0 >>>> Did you load a gadget driver ? >>>> Which gadget driver did you load ? >>>> >>> It's gadget zero. At least it's reported in dwc3_gadget_run_stop() - >>> see the last line in dwc3-init.trace: >>> insmod-95 [000] d..2 603.695374: dwc3_gadget: gadget zero data >>> soft-connect >> okay, I really have no idea what's going on with your SoC. This works >> fine with skylake, broxton and some other Intel SoCs I have around. > I have E3800 only ( >> If this fails the same way with WindRiver provided kernel, I'd say you >> should really contact them because I have no information on this SoC >> you're using. >> >> Just to be sure, you're using vanilla v4.6-rc4 ? > > vanilla 4.6.0-rc3+ > >> no changes whatsoever > 2 changes: > 1) added platform drivers in linux/drivers/platform/ > should not influence dwc3 > 2) the only dwc3 -related change is in dwc3_pci_quirks(): > I need different "baytrail" quirk - smsc 3310 does not have CS. So I > request appropriate gpio and set it "out high" to get phy out of reset. > ULPI clocks are enabled earlier in bootcode (via GEN_REGRW1) - so don't > handle it in dwc3 code. okay, so basically you have enough code to get your PHY working on your board. That really shouldn't matter. I'm very much interested in understanding what's going on, but considering the exact same problem happens with WindRiver provided kernel, I'd bet on something outside the kernel being the culprit. Do you have proper tools to run USB electrical tests ? They're not very common, but maybe your company has them... -- balbi
Attachment:
signature.asc
Description: PGP signature
