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

[Roger Quadros]

On 12/02/2013 04:03 PM, Sebastian Andrzej Siewior wrote:
> 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".
> 

We are already telling hwmod to not use smart-idle or smart-standby.
So the device is always put in no-idle,no-standby during resume and force-idle,force-standby
during suspend.

I'll send a new patch to remove "do-not-reset" flag from hwmod data and then we
don't need this patch.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/