Hi Paul, > > I remember when bringing up the driver, that the sleep at the end of > > dwc2_core_reset() was very critical to making host mode work. Maybe > > you could experiment with that also. > I'll have a look next week, thanks.
I tried doubling the delay in dwc2_core_reset, but that didn't seem to make a difference. I did notice that this problem does not occur with all devices. So far I've only seen it with a few mass storage devices (also tried some wifi and 3G dongles). In particular, it occurse with the all three Intenso Premium [1] sticks I tried (4GB, 8GB and 16GB), as well as some non-name stick I had here (058f:6387 Alcor Micro Corp. Flash Drive). [1]: http://www.intenso.de/produkte.php?kategorie=23&&produkt=1255723475 I also noticed that the problem only occurs when actually disconnecting the power. I could not reproduce the problem on a dozen soft resets (using the "reboot" command in OpenWRT), though the problem can _persist_ through a soft reset if the device is (still or again) plugged in at reset time (see below). The problem seems to occur both when disconnecting the power adapter from the wall socket as well as when disconnecting the power adapter from the Fonera (I was thinking that caps in the adapter might somehow be causing brownout or something like that). When doing hard reboots by shortly (± 1 second) disconnecting the power, this morning the problem seemed to occur every other boot (i.e., a short power cut breaks the hardware, but also fixes it). Now, however I'm seeing different behaviour (with the same kernel): a short power disconnect is enough to break the hardware, but it needs a longer (80-90 seconds) power disconnect to start working again. It seems the problem is triggered when: - there is a short power cut and - there is a device plugged in at poweron (I have seen one or two times when the problem did not trigger under these conditions, but it's mostly reproducible) or - the problem was present on the previous boot - a soft reset is done - there is a device plugged in at reset time This second set of conditions is particularly puzzling to me. The problem is not triggered when: - The power was off for longer (threshold seems to be around 80-90 seconds), or - No device is plugged in at poweron - a soft reset was done and the problem was not present on the previous boot The problem did not occur when plugging in the device after power on, not even when plugging it in within a second of power on. Having it plugged in or out on powerdown did not seem to influence the results. I tried doing a complete reset at hcd_init time (the RT3052 SoC has this global reset registers that allows you to entirely reset parts of the SoC), but that didn't change things either. I'm thinking that somehow the PHY might be in an undefined state, but I couldn't really find any way to somehow force the PHY to be reset. Is there any generic way, or would that be platform-specific? Gr. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
