From: Kevin Hilman <khilman@linaro.org>
To: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Rajendra Nayak <rnayak@ti.com>,
Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
vaibhav.bedia@ti.com, linux-arm-kernel@lists.infradead.org,
mpfj-list@newflow.co.uk, Sourav Poddar <sourav.poddar@ti.com>,
paul@pwsan.com
Subject: Re: [PATCH] arm: omap2plus: unidle devices which are about to probe
Date: Sat, 13 Jul 2013 23:21:29 +0100 [thread overview]
Message-ID: <8738rije3a.fsf@linaro.org> (raw)
In-Reply-To: <1373537788-30413-1-git-send-email-balbi@ti.com> (Felipe Balbi's message of "Thu, 11 Jul 2013 13:16:28 +0300")
Felipe Balbi <balbi@ti.com> writes:
> in order to make HWMOD and pm_runtime agree on the
> initial state of the device, we will unidle the device
> and call pm_runtime_set_active() to tell pm_runtime
> that the device is really active.
>
> By the time driver's probe() is reached, a call to
> pm_runtime_get_sync() will not cause driver's
> ->runtime_resume() method to be called at first, only
> after a successful ->runtime_suspend().
>
> Note that we must prevent pm_runtime transitions while
> driver is probing otherwise drivers would be suspended
> as soon as they call pm_runtime_use_autosuspend(). By
> calling pm_runtime_forbid() before probe() and
> pm_runtime_allow() after probe() we 'fix' that detail.
This part sounds a bit strange to me, and sounds more like a driver bug.
Looking at omap-serial, this probably happens because the driver calls
_use_autosuspend() after it has called _enable() but before has done its
_get_sync().
> Note that this patch was inspired by PCI's pci_pm_init().
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> boot tested on top of today's Linus master
> 6d128e1e72bf082542e85f72e6b7ddd704193588 with OMAP4
> panda. Reached console prompt and, after setting a
> proper autosuspend delay, consoles autosuspend just
> fine.
>
> It needs to be tested on other platforms.
>
> ps: note that we also call pm_runtime_set_suspended(dev)
> from our late_initcall() to disable devices so that pm_runtime
> and HWMOD continue to aggree on device's state.
Excellent.
I like this approach, but agree it needs more testing like you
mentioned.
> arch/arm/mach-omap2/omap_device.c | 44 +++++++++++++++++++++++++++++++++++----
> 1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index 5cc9287..cb1fc1d 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -178,6 +178,26 @@ odbfd_exit:
> return ret;
> }
>
> +static void omap_device_pm_init(struct platform_device *pdev)
> +{
> + omap_device_enable(pdev);
> + pm_runtime_forbid(&pdev->dev);
> + pm_runtime_set_active(&pdev->dev);
> + device_enable_async_suspend(&pdev->dev);
You don't comment in the changelog about what this is for. I think we
probably want this, but I suspect it belongs in a follow-up patch with
its own changelog.
Also Like PCI, I think we also want the device_set_wakeup_capable() here
also, but that should have its own patch+changelog also.
Kevin
next prev parent reply other threads:[~2013-07-13 22:21 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-04 13:25 Boot hang regression 3.10.0-rc4 -> 3.10.0 Mark Jackson
2013-07-04 15:14 ` Mark Jackson
2013-07-04 16:00 ` Mark Jackson
2013-07-05 8:11 ` Bedia, Vaibhav
2013-07-05 11:59 ` Tony Lindgren
2013-07-05 13:20 ` Bedia, Vaibhav
2013-07-05 13:31 ` Bedia, Vaibhav
2013-07-08 11:25 ` Tony Lindgren
2013-07-08 12:16 ` Tony Lindgren
2013-07-08 12:41 ` Rajendra Nayak
2013-07-08 13:10 ` Tony Lindgren
2013-07-08 13:20 ` Rajendra Nayak
2013-07-08 13:25 ` Rajendra Nayak
2013-07-08 13:35 ` Felipe Balbi
2013-07-09 5:33 ` Rajendra Nayak
2013-07-09 6:42 ` Felipe Balbi
2013-07-09 7:19 ` Rajendra Nayak
2013-07-09 7:40 ` Felipe Balbi
2013-07-09 18:59 ` Grygorii Strashko
2013-07-09 19:41 ` Felipe Balbi
2013-07-10 12:16 ` Grygorii Strashko
2013-07-10 12:25 ` Felipe Balbi
2013-07-10 8:22 ` Kevin Hilman
2013-07-10 12:10 ` Tony Lindgren
2013-07-10 12:27 ` Tony Lindgren
2013-07-10 14:26 ` Tony Lindgren
2013-07-10 16:07 ` Felipe Balbi
2013-07-10 16:11 ` Felipe Balbi
2013-07-11 6:32 ` Tony Lindgren
2013-07-11 9:59 ` Grygorii Strashko
2013-07-12 0:40 ` Suman Anna
2013-07-15 6:44 ` Rajendra Nayak
2013-07-15 10:01 ` Rajendra Nayak
2013-07-15 19:23 ` Suman Anna
2013-07-16 6:30 ` Rajendra Nayak
2013-07-11 9:17 ` Rajendra Nayak
2013-07-11 9:26 ` Felipe Balbi
2013-07-11 10:16 ` [PATCH] arm: omap2plus: unidle devices which are about to probe Felipe Balbi
2013-07-12 11:58 ` Grygorii Strashko
2013-07-12 12:10 ` Felipe Balbi
2013-07-12 12:27 ` Rajendra Nayak
2013-07-13 22:21 ` Kevin Hilman [this message]
2013-07-11 9:59 ` Boot hang regression 3.10.0-rc4 -> 3.10.0 Grygorii Strashko
2013-07-16 10:27 ` Grygorii Strashko
2013-07-17 7:10 ` Rajendra Nayak
2013-07-11 6:18 ` Rajendra Nayak
2013-07-11 6:24 ` Tony Lindgren
2013-07-11 9:11 ` Rajendra Nayak
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=8738rije3a.fsf@linaro.org \
--to=khilman@linaro.org \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=mpfj-list@newflow.co.uk \
--cc=paul@pwsan.com \
--cc=rnayak@ti.com \
--cc=sourav.poddar@ti.com \
--cc=tony@atomide.com \
--cc=vaibhav.bedia@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).