On Mon, Mar 11, 2013 at 1:15 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > 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? Soft reset seems to recover from this so there is no problem, but you can't reset before every suspend so a workaround is still needed.. >> 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? Well as long as it works it's good for me, although it'll bloat the code a bit compared to just changing the data. Should I attempt an implementation? -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
