Hi Russ,
Russ Dill <russ.d...@ti.com> writes:
> After the gpio-omap runtime PM changes, I noticed that the
> omap2_gpio_prepare_for_idle/omap2_gpio_resume_after_idle functions are
> a NOP in the case of suspend.
>
> void omap2_gpio_prepare_for_idle(int pwr_mode)
> {
> struct gpio_bank *bank;
>
> list_for_each_entry(bank, &omap_gpio_list, node) {
> if (!bank->mod_usage)
> continue;
>
> bank->power_mode = pwr_mode;
>
> pm_runtime_put_sync_suspend(bank->dev);
> }
> }
>
> void omap2_gpio_resume_after_idle(void)
> {
> struct gpio_bank *bank;
>
> list_for_each_entry(bank, &omap_gpio_list, node) {
> if (!bank->mod_usage)
> continue;
>
> pm_runtime_get_sync(bank->dev);
> }
> }
>
> (called from omap_pm_enter->omap3_pm_suspend->omap_sram_idle)
>
> At the point that platform_suspend_ops.enter is called,
> dpm_suspend_end has already been called which disables runtime_pm.
> During a suspend/resume where power is lost to certain GPIO banks, the
> context will not be restored.
Did you actually observe context not being restored, or is this an
observation by looking at the code?
The PM domain layer (implemented in omap_device) is supposed to be
handling the case where runtime PM has been disabled by the PM core.
Specifically, check the 'noirq' hooks in the omap_device PM domain.
These check whether omap_devices are runtime_suspended, and
runtime_suspends them if they are not. Then during resume, the
resume_noirq hook will runtime resume them if they were "forcibly"
runtime suspended during the noirq phase.
That being said, there may have been some recent PM core changes that
have caused this not to work anymore, so I'd be very curious exactly how
to reproduce this.
Thanks,
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
