Govindraj <govindraj.ti@xxxxxxxxx> writes:
> On Sat, Jun 25, 2011 at 5:59 AM, Kevin Hilman <khilman@xxxxxx> wrote:
>> "Govindraj.R" <govindraj.raja@xxxxxx> writes:
>>
>>> Prior to this patch the uart_clock was cut using prepare/resume calls since
>>> these funcs are no more available with runtime changes use has_async_wake
>>> flag to keep clock active during bootup otherwise uart port will disabled
>>> during boot-up and cannot be enabled back.
>>
>> Is this only a bootup issue, or a runtime PM issue? It appears to me
>> that with this patch, runtime PM is effectively disabled for the whole
>> time.
>>
>
> it boots up fine, its a runtime PM issue where there is
> no mechanism to wakeup after clock cutting from
> runtime autosuspend.
>
>
>> Why not just use pm_runtime_disable() in _probe() for devices with no
>> async wakeup.
>>
>
> Agree.
> can drop of this patch and bind below changes in runtime conversion patch 04/12
>
> do pm_runtime_enable only if device_may_wakeup
> is true in probe.
>
> <<SNIP>>
> in serial_omap_probe
>
> if (device_may_wakeup(&pdev->dev)) {
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_set_autosuspend_delay(&pdev->dev,
> OMAP_UART_AUTOSUSPEND_DELAY);
> pm_runtime_enable(&pdev->dev);
> pm_runtime_irq_safe(&pdev->dev);
> }
Well, I think only the _enable() should be conditional.
>>> Also based on this flag we can disable uart port during suspend and
>>> enable back during resume for omap_socs that have not set
>>> has_async_wake.
>>
>> Then you can use pm_runtime_enable() in ->prepare() and
>> pm_runtime_disable() in ->complete()
>>
>
> u mean runtime enable in suspend and runtime disable in resume
> if device_may_wakeup is false.
No, I meant the .prepare (runs before .suspend) and .complete (runs
after .resume) callbacks.
Kevin
--
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
