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

Grazvydas Ignotas notasas at gmail.com
Mon Mar 11 12:43:19 EDT 2013


On Mon, Mar 11, 2013 at 1:15 AM, Paul Walmsley <paul at pwsan.com> 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



More information about the linux-arm-kernel mailing list