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

[Roger Quadros]

On 12/02/2013 03:39 PM, Sebastian Andrzej Siewior wrote:
> On 12/02/2013 02:35 PM, Roger Quadros wrote:
>>> It refers to "Errata Id:i660" why it is required. Once you figured what
>>> why it has been added you could have an idea if it is okay to remove it
>>> and if the reset you do here might lead to it (I dunno).
>>>
>>
>> Keshava no longer works @TI. I have no other means to check why it was added
>> other than doing dome tests and making sure nothing breaks if we remove it.
>>
>> So far, things are going fine for about 50 or so boots divided between OMAP3 and 4
>> platforms. If more people can test and give feedback it'd be great.
> 
> Hmm. Can't you lookup the errata he revers to?
> 

Sure, but it was not making sense why RESET was avoided.
It doesn't say anything about not using RESET. In fact it says that RESET _is_ the
recovery procedure.

Pasting the errata description below for easy reference.

"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.

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/