Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support

[Dave Gerlach <d-gerlach@ti.com>]

On 08/20/2013 05:48 PM, Paul Walmsley wrote:
>
> Hi folks,
>
> catching up on this thread.
>
> On 08/06/2013 12:49 PM, Dave Gerlach wrote:
>
>> +
>> +static int am33xx_pm_suspend(void)
>> +{
>> +     int i, j, ret = 0;
>> +
>> +     int status = 0;
>> +     struct platform_device *pdev;
>> +     struct omap_device *od;
>> +
>> +     /*
>> +      * By default the following IPs do not have MSTANDBY asserted
>> +      * which is necessary for PER domain transition. If the drivers
>> +      * are not compiled into the kernel HWMOD code will not change the
>> +      * state of the IPs if the IP was not never enabled. To ensure
>> +      * that there no issues with or without the drivers being compiled
>> +      * in the kernel, we forcefully put these IPs to idle.
>> +      */
>> +     for (i = 0; i < ARRAY_SIZE(am33xx_mod); i++) {
>> +             pdev = to_platform_device(am33xx_mod[i].dev);
>> +             od = to_omap_device(pdev);
>> +             if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
>> +                     omap_device_enable_hwmods(od);
>> +                     omap_device_idle_hwmods(od);
>> +             }
>> +     }
>
> Does this have to be done for every suspend entry, or can it just be done
> once during kernel initialization?
>
> If the latter, shouldn't this be done by hwmod during the initial reset
> and idle of all of these devices, based on a flag?  For example, we had
> this flag for OMAP3630:
>
>   * HWMOD_FORCE_MSTANDBY: Always keep MIDLEMODE bits cleared so that device
>   *     is kept in force-standby mode. Failing to do so causes PM problems
>   *     with musb on OMAP3630 at least. Note that musb has a dedicated
> register
>   *     to control MSTANDBY signal when MIDLEMODE is set to force-standby.
>

Hi,
Unfortunately this does have to be done at some point after every 
suspend/resume cycle because while the IPs are idled during initial 
reset, after a suspend cycle the context loss when no driver is bound 
causes MSTANDBY to be unasserted again which as mentioned breaks the PER 
power domain transition during the next suspend attempt.

The current plan for this is somewhat similar to what you mentioned, all 
of the troublesome modules will be flagged in hwmod and when the hwmods 
are loaded they are tracked if no driver gets bound and then idled post 
resume by a pm_notifier.

Regards,
Dave

>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>