Hi, Kirill Dronov <cyrill.dronov@xxxxxxxxx> writes: >>>>> 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 DWC3 >>>> we 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. > I've tried latest mainline: 4.6.0-rc3+ (HEAD of > github.com/torvalds/linux.git). > > 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. interesting. I'll go over your logs. >> BTW, your trace output looks really odd. Seems like you're getting a ton >> of spurious IRQs. > Well, I see lot of dwc3_gadget_linksts_change_interrupt() but I don't > know if such states sequence is correct/expected: > 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? it depends :-) If the PIPE3 interface was properly terminated, then RxDetection should just fail silently, otherwise there might be issues. But, since you're getting all the way to conndone in HS and then see a GetDescriptor request, I'm assuming that to be the case. > Is something definitely wrong with initialization and enumeration traces? I'll go read them > I see that TUSB1210 was tested with Baytrail board. Are there any other > known working Baytrail/phy2 combinations (my phy is smsc usb3310)? no idea > Sorry for my generic questions - more specific can be answered by > Databook that I don't have. you won't get it from this forum either; you need to talk to your company lawyer and figure what sort of agreements you need to sign in order to get access to that document >> 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. that's yet to be proven :-) I don't have access to the SoC you have around either. -- balbi
Attachment:
signature.asc
Description: PGP signature
