Re: [PATCH 1/1] mfd: omap-usb-host: Fix USB device detection problems on OMAP4 Panda

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

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