From: Kevin Hilman <khilman@deeprootsystems.com>
To: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>, Paul Walmsley <paul@pwsan.com>,
Santosh Shilimkar <santosh.shilimkar@ti.com>,
Linux OMAP Mailing List <linux-omap@vger.kernel.org>,
Linux ARM Kernel Mailing List
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq
Date: Thu, 18 Oct 2012 09:34:15 -0700 [thread overview]
Message-ID: <871ugvivso.fsf@deeprootsystems.com> (raw)
In-Reply-To: <1350488043-5053-2-git-send-email-balbi@ti.com> (Felipe Balbi's message of "Wed, 17 Oct 2012 18:33:59 +0300")
Felipe Balbi <balbi@ti.com> writes:
> current implementation doesn't take care about
> drivers which don't provide *_noirq methods
The generic ops handle this. See below.
> and we could fall into a situation where we would suspend/resume
> devices even though they haven't asked for it.
The following explanation doesn't explain this, so I dont' follow
the "even though they haven't asked for it" part.
> One such case happened with the I2C driver which
> was getting suspended during suspend_noirq() just
> to be resume right after by any other device doing
> an I2C transfer on its suspend method.
In order to be I2C to be runtime resumed after its noirq method has been
called, that means the other device is doing an I2C xfer in its noirq
method. That is a bug.
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
> arch/arm/plat-omap/omap_device.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 7a7d1f2..935f416 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -804,8 +804,12 @@ static int _od_suspend_noirq(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct omap_device *od = to_omap_device(pdev);
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> int ret;
>
> + if (!pm || !pm->suspend_noirq)
> + return 0;
> +
you just re implemented pm_generic_suspend_noirq() (c.f. drivers/base/power/generic_ops.c)
> /* Don't attempt late suspend on a driver that is not bound */
> if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER)
> return 0;
> @@ -827,6 +831,10 @@ static int _od_resume_noirq(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> struct omap_device *od = to_omap_device(pdev);
> + const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
> +
> + if (!pm || !pm->resume_noirq)
> + return 0;
and this is basically pm_generic_resume_noirq()
>
> if ((od->flags & OMAP_DEVICE_SUSPENDED) &&
> !pm_runtime_status_suspended(dev)) {
Kevin
next prev parent reply other threads:[~2012-10-18 16:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 15:33 [RFC/NOT FOR MERGING 0/5] OMAP PM patches Felipe Balbi
2012-10-17 15:33 ` [RFC/NOT FOR MERGING 1/5] arm: omap: fix up _od_suspend_noirq and _od_resume_noirq Felipe Balbi
2012-10-18 16:34 ` Kevin Hilman [this message]
2012-10-18 16:55 ` Felipe Balbi
2012-10-18 17:42 ` Kevin Hilman
2012-10-18 17:50 ` Felipe Balbi
2012-10-18 18:42 ` Kevin Hilman
2012-10-18 19:34 ` Felipe Balbi
2012-10-18 20:47 ` Kevin Hilman
2012-10-18 20:58 ` Kevin Hilman
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 2/5] arm: omap: don't forcefully runtime suspend a device Felipe Balbi
2012-10-18 17:01 ` Kevin Hilman
2012-10-18 17:05 ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 3/5] arm: omap: introduce other PM methods Felipe Balbi
2012-10-18 17:07 ` Kevin Hilman
2012-10-18 17:06 ` Felipe Balbi
2012-10-18 17:23 ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 4/5] i2c: omap: don't re-enable IRQs after masking them Felipe Balbi
2012-10-18 17:10 ` Kevin Hilman
2012-10-18 17:07 ` Felipe Balbi
2012-10-17 15:34 ` [RFC/NOT FOR MERGING 5/5] i2c: omap: introduce suspend/resume methods Felipe Balbi
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=871ugvivso.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=balbi@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.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).