On 12/02/2013 02:44 PM, Roger Quadros wrote: > "Errata id: i660 > DESCRIPTION > In the following configuration : > • USBHOST module is set to smart-idle mode > • PRCM asserts idle_req to the USBHOST module. (This typically happens when the system is going to > a low power mode : all ports have been suspended, the master part of the USBHOST module has > entered the standby state, and SW has cut the functional clocks.) > • an USBHOST interrupt occurs before the module is able to answer idle_ack, typically a remote wakeup > IRQ. > Then the USB HOST module will enter a deadlock situation where it is no more accessible nor functional. > The only way to recover will be to perform a software reset of the module. > > WORKAROUND > The best workaround consists in switching the module to force idle mode right before cutting the > module's FCLK. > • the bus has reached the suspend state. > • write SYSCONFIG:Idlemode= ForceIdle and read it back to ensure the write has been taken into > account in case of posted writes. > • cut the FCLK > • Idle_req will be asserted and idle_ack answered within one L3 clock cycle. > Upon resume or remote wakeup, switch back the module to smart-idle. > This workaround reduces the failure window to only one L3 clock cycle. The probability for an interrupt to > fire at this exact time is considered extremely low, and the case has never been hit on board." > > Based on this, I don't see anything wrong in Resetting the module at probe or at boot. If u-boot configured USB into something not smart-idle and the reset would bring it back then the reset should remain. If you could tell hwmod not use smart-idle nor smart-standby and you make sure that the suspend code manually puts the device into suspend via forceidle then I think could get rid of the "do-not-reset-thingy". > > cheers, > -roger > Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
