Kirill Dronov <cyrill.dronov@xxxxxxxxx> writes: >>>> 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... >> > I suppose they have. What test procedure can you recommend? Get an eye diagram and check that signal quality is within compliance. Basically you connect your board to a scope through a test fixture and start sending test packets (this is exposed on debugfs for dwc3, see drivers/usb/dwc3/debugfs.c), then the scope will generate an eye diagram and, assuming you have access to the proper scope, give you a pass/fail result. http://www.usb.org/developers/compliance/electrical_tests/ has more information and all procedures for all tests. -- balbi
Attachment:
signature.asc
Description: PGP signature
