On 11/06/2014 01:07 PM, Sebastian Andrzej Siewior wrote:
> This is mostly an equivalent for the 8250-omap driver based on a patch
> of Dave Gerlach for the omap-serial driver (which is not yet merged).
>
> From his changelog:
> |By optionally putting the pins into sleep state in the suspend callback
> |we can accomplish two things.
> |- minimize current leakage from pins and thus save power,
> |- prevent the IP from driving pins output in an uncontrolled manner,
> | which may happen if the power domain drops the domain regulator.
>
> The pinctlr change is put before enable_wakeup logic as per Nishanth
> Menon (slightly reworded):
> |When wakeup is enabled, I/O daisy chain based wakeup is used by
> |reconfiguring the padconfig register. However, this gets overriden by
> |sleep/wakeup configuration. Therefore we need first to allow pinctrl to
> |play with the wakeup bits as needed beyond the sleep configuration.
>
> Cc: Dave Gerlach <d-gerlach@xxxxxx>
> Cc: Nishanth Menon <nm@xxxxxx>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>
> ---
> drivers/tty/serial/8250/8250_omap.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 57a8b1241b85..1681875f2996 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1156,6 +1156,7 @@ static int omap8250_suspend(struct device *dev)
> serial8250_suspend_port(priv->line);
> flush_work(&priv->qos_work);
>
> + pinctrl_pm_select_sleep_state(dev);
> if (device_may_wakeup(dev))
> omap8250_enable_wakeup(priv, true);
> else
> @@ -1167,6 +1168,7 @@ static int omap8250_resume(struct device *dev)
> {
> struct omap8250_priv *priv = dev_get_drvdata(dev);
>
> + pinctrl_pm_select_default_state(dev);
> if (device_may_wakeup(dev))
> omap8250_enable_wakeup(priv, false);
>
>
sounds good to me *IF* omap8250_enable_wakeup (wakeirq handling) is
the way we want to continue doing things for daisychain? -> Tony, can
you comment?
http://marc.info/?l=linux-omap&m=141222144402707&w=2
I wonder if wakeirq explicit handling is valid anymore and something
given the potential race and alternate approach proposed?
--
Regards,
Nishanth Menon
--
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
