[PATCH] ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb

[Paul Walmsley]

Hi Gražvydas,

On Sun, 10 Mar 2013, Grazvydas Ignotas wrote:

> For some unknown reason, allowing hwmod to control MIDLEMODE causes
> core_pwrdm to not hit idle states for musb in DM3730 at least.
> I've verified that setting any MIDLEMODE value other than "force
> standby" before enabling the device causes subsequent suspend
> attempts to fail with core_pwrdm not entering idle states, even
> if the driver is unloaded and "force standby" is restored before
> suspend attempt.

Ugh sounds like a broken bootloader/previous OS could easily block full 
chip idle in this case :-( Does that match your understanding?  That, even 
if the new kernel does everything right in terms of initialization and 
reset, the PRCM's perception of whether the device is in STANDBY is 
permanently stuck?

> Keeping the register set at force standby (reset value) makes it work
> and device still functions properly. musb has driver-controlled
> OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps
> MIDLEMODE is not even needed? Note that TI PSP kernels also have
> similar workarounds.

Would like to get your opinion on a different implementation.  For other
situations where IP blocks don't work in the standard, expected way, we've 
defined hwmod flags for those situations, like HWMOD_SWSUP_*, and 
HWMOD_NO_OCP_AUTOIDLE.  The motivation is to affirmatively mark IP 
blocks that don't work as expected, rather than changing the existing, 
documented hardware bits, which are ideally autogenerated.

So what do you think about adding a hwmod flag, HWMOD_FORCE_MSTDBY, and 
using that in the hwmod code to program the MSTDBYMODE to FORCE_STANDBY 
and then skipping all other attempts to write to it?


- Paul