From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Pritesh Raithatha
<praithatha-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] pinctrl: tegra: add suspend/resume support
Date: Thu, 01 Nov 2012 11:23:19 -0600 [thread overview]
Message-ID: <5092B007.7050609@wwwdotorg.org> (raw)
In-Reply-To: <1351785186-11431-1-git-send-email-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 11/01/2012 09:53 AM, Dmitry Osipenko wrote:
> Added suspend/resume pm ops. We need to store current regs vals on suspend and
> restore them on resume.
Interesting. Just literally a couple days ago, I was reviewing a patch
to our internal kernel tree that implemented the same thing for the
pinctrl driver, in almost the same way!
> ---
> Tested on my tablet.
I'm curious how; in what environment. As far as I know, the Tegra
support in the mainline kernel doesn't actually support suspend/resume.
I assume you cherry-picked this pinctrl driver into some other kernel,
and tested this patch there?
> +#ifdef CONFIG_PM_SLEEP
> +static int tegra_pinctrl_suspend_noirq(struct device *dev)
The one major different between this patch and the downstream patch I
reviewed is how suspend/resume is triggered. This uses suspend_noirq,
whereas the downstream patch registers the callbacks using
register_syscore_ops(). Apparently the latter is required (at least in
our downstream kernel) in order to ensure that pinctrl gets suspended
after all other drivers.
I Cc'd Pritesh to comment on this.
Still, perhaps device probe ordering should ensure this upstream so
using register_syscore_ops() might not be necessary, although that
relies on drivers probing in the correct order, which they may not
without explicitly pinctrl_get() calls... back to that same problem again!
...
> +static const struct dev_pm_ops tegra_pinctrl_pm_ops = {
> + .suspend_noirq = tegra_pinctrl_suspend_noirq,
> + .resume_noirq = tegra_pinctrl_resume_noirq,
> +};
> +#define TEGRA_PINCTRL_PM (&tegra_pinctrl_pm_ops)
> +#else
> +#define TEGRA_PINCTRL_PM NULL
> +#endif
I was going to suggest using something like SET_SYSTEM_SLEEP_PM_OPS, but
I guess there's no equivalent for the _noirq variants.
> @@ -752,6 +838,8 @@ int __devinit tegra_pinctrl_probe(struct platform_device *pdev,
>
> platform_set_drvdata(pdev, pmx);
>
> + pdev->dev.driver->pm = TEGRA_PINCTRL_PM;
That might be better done in the struct platform_driver initialization
in pinctrl-tegra*.c?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Dmitry Osipenko <digetx@gmail.com>,
Pritesh Raithatha <praithatha@nvidia.com>
Cc: linus.walleij@linaro.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] pinctrl: tegra: add suspend/resume support
Date: Thu, 01 Nov 2012 11:23:19 -0600 [thread overview]
Message-ID: <5092B007.7050609@wwwdotorg.org> (raw)
In-Reply-To: <1351785186-11431-1-git-send-email-digetx@gmail.com>
On 11/01/2012 09:53 AM, Dmitry Osipenko wrote:
> Added suspend/resume pm ops. We need to store current regs vals on suspend and
> restore them on resume.
Interesting. Just literally a couple days ago, I was reviewing a patch
to our internal kernel tree that implemented the same thing for the
pinctrl driver, in almost the same way!
> ---
> Tested on my tablet.
I'm curious how; in what environment. As far as I know, the Tegra
support in the mainline kernel doesn't actually support suspend/resume.
I assume you cherry-picked this pinctrl driver into some other kernel,
and tested this patch there?
> +#ifdef CONFIG_PM_SLEEP
> +static int tegra_pinctrl_suspend_noirq(struct device *dev)
The one major different between this patch and the downstream patch I
reviewed is how suspend/resume is triggered. This uses suspend_noirq,
whereas the downstream patch registers the callbacks using
register_syscore_ops(). Apparently the latter is required (at least in
our downstream kernel) in order to ensure that pinctrl gets suspended
after all other drivers.
I Cc'd Pritesh to comment on this.
Still, perhaps device probe ordering should ensure this upstream so
using register_syscore_ops() might not be necessary, although that
relies on drivers probing in the correct order, which they may not
without explicitly pinctrl_get() calls... back to that same problem again!
...
> +static const struct dev_pm_ops tegra_pinctrl_pm_ops = {
> + .suspend_noirq = tegra_pinctrl_suspend_noirq,
> + .resume_noirq = tegra_pinctrl_resume_noirq,
> +};
> +#define TEGRA_PINCTRL_PM (&tegra_pinctrl_pm_ops)
> +#else
> +#define TEGRA_PINCTRL_PM NULL
> +#endif
I was going to suggest using something like SET_SYSTEM_SLEEP_PM_OPS, but
I guess there's no equivalent for the _noirq variants.
> @@ -752,6 +838,8 @@ int __devinit tegra_pinctrl_probe(struct platform_device *pdev,
>
> platform_set_drvdata(pdev, pmx);
>
> + pdev->dev.driver->pm = TEGRA_PINCTRL_PM;
That might be better done in the struct platform_driver initialization
in pinctrl-tegra*.c?
next prev parent reply other threads:[~2012-11-01 17:23 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-01 15:53 [PATCH] pinctrl: tegra: add suspend/resume support Dmitry Osipenko
2012-11-01 15:53 ` Dmitry Osipenko
[not found] ` <1351785186-11431-1-git-send-email-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-01 17:23 ` Stephen Warren [this message]
2012-11-01 17:23 ` Stephen Warren
[not found] ` <5092B007.7050609-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-01 20:08 ` Dmitry Osipenko
[not found] ` <5092D6A5.5010401-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-01 21:35 ` Stephen Warren
[not found] ` <5092EB25.5020404-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-03 0:30 ` [PATCH V2] " Dmitry Osipenko
[not found] ` <1351902619-911-1-git-send-email-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-05 9:06 ` Pritesh Raithatha
2012-11-05 16:57 ` Stephen Warren
[not found] ` <5097F013.8070002-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-06 1:37 ` [PATCH V3] " Dmitry Osipenko
[not found] ` <1352165844-4837-1-git-send-email-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-06 3:41 ` Stephen Warren
[not found] ` <50988701.5080602-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-06 13:08 ` Dmitry Osipenko
2012-11-06 13:08 ` Dmitry Osipenko
[not found] ` <50990BE0.9040507-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-06 17:38 ` Stephen Warren
[not found] ` <50994AFB.8000802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-06 20:06 ` Dmitry Osipenko
2012-11-06 20:06 ` Dmitry Osipenko
[not found] ` <50996DCC.8030508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-06 21:45 ` Stephen Warren
[not found] ` <509984F9.1060508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-06 22:14 ` Dmitry Osipenko
2012-11-06 22:14 ` Dmitry Osipenko
2013-03-05 0:13 ` Dmitry Osipenko
[not found] ` <513538BC.5070706-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-03-05 0:38 ` Stephen Warren
2012-11-06 17:40 ` Stephen Warren
2012-11-06 10:28 ` Pritesh Raithatha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5092B007.7050609@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=praithatha-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.