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
