linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).