From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Grazvydas Ignotas <notasas@gmail.com>,
Rajendra Nayak <rnayak@ti.com>,
jaswinder.singh@linaro.org, mythripk@ti.com,
linux-omap@vger.kernel.org, linux-fbdev@vger.kernel.org,
andy.green@linaro.org, n-dechesne@ti.com,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-pm@vger.kernel.org
Subject: Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
Date: Tue, 26 Jun 2012 18:01:15 +0300 [thread overview]
Message-ID: <1340722875.24530.66.camel@deskari> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1206261031450.1636-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 1951 bytes --]
On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote:
> On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
>
> > CCing some PM people, maybe they can comment?
> >
> > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak <rnayak@ti.com> wrote:
> > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> > >>
> > >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
> > >> Are they supposed to handle the error values returned by runtime PM
> > >> functions somehow, or should they use #ifdef CONFIG_PM_RUNTIME?
> > >
> > > hmm, I always though with CONFIG_RUNTIME_PM=n, the functions would
> > > be stubbed to return success and not failure.
>
> Not exactly. They are stubbed to indicate that the device cannot be
> suspended, that it is always active.
>
> Failure to suspend a device should not be regarded as particularly bad,
> because it doesn't affect the device's functionality. That's true even
> when CONFIG_RUNTIME_PM is enabled.
This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_runtime_get_sync()
will return 1, meaning the HW is already enabled, and using
pm_runtime_put_sync() will return -ENOSYS, meaning the hardware cannot
be suspended.
With CONFIG_RUNTIME_PM=y, it's a bit more complex. If I read the code
correctly, when I call pm_runtime_get_sync(), the usage counter is
always increased, even if the pm_runtime_resume() fails. So a get()
needs to be always matched with a put(), even if get() has returned an
error.
But if pm_runtime_get_sync() returns an error, it means the HW has not
been resumed successfully, and is not operational, so the code should
bail out somehow. So basically I'd use this kind of pattern everywhere I
use pm_runtime_get_sync():
---
r = pm_runtime_get_sync(dev);
if (r < 0) {
pm_runtime_put_sync(dev);
/* handle error */
return -ESOMETHING;
}
/* do the work */
pm_runtime_put_sync(dev);
---
Is this correct?
Tomi
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-06-26 15:01 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-23 8:06 [PATCH] OMAPDSS: Check if RPM enabled before trying to change state jaswinder.singh
2012-06-25 6:20 ` Tomi Valkeinen
2012-06-25 8:49 ` Jassi Brar
2012-06-25 9:30 ` Tomi Valkeinen
2012-06-25 12:27 ` Jassi Brar
2012-06-25 12:41 ` Tomi Valkeinen
2012-06-25 13:31 ` Jassi Brar
2012-06-25 13:49 ` Tomi Valkeinen
2012-06-25 17:06 ` Jassi Brar
2012-06-26 7:19 ` Tomi Valkeinen
2012-06-26 8:32 ` Jassi Brar
2012-06-26 8:40 ` Andy Green
2012-06-26 9:07 ` Tomi Valkeinen
2012-06-26 9:57 ` Jassi Brar
2012-06-26 12:03 ` Tomi Valkeinen
2012-06-26 14:49 ` Jassi Brar
2012-06-26 15:08 ` Tomi Valkeinen
2012-06-26 15:09 ` Jassi Brar
2012-06-26 15:11 ` Tomi Valkeinen
2012-06-26 17:01 ` Jassi Brar
2012-06-26 18:44 ` Tomi Valkeinen
2012-06-27 4:42 ` Jassi Brar
2012-06-27 5:58 ` Tomi Valkeinen
2012-06-27 7:41 ` Jassi Brar
2012-06-27 8:13 ` Tomi Valkeinen
2012-06-27 14:53 ` Jassi Brar
2012-06-28 6:41 ` Tomi Valkeinen
2012-06-28 7:46 ` Jassi Brar
2012-06-28 7:58 ` Tomi Valkeinen
2012-06-25 12:05 ` Grazvydas Ignotas
2012-06-25 12:30 ` Tomi Valkeinen
2012-06-25 12:42 ` Rajendra Nayak
2012-06-25 12:50 ` Tomi Valkeinen
2012-06-26 4:51 ` Rajendra Nayak
2012-06-26 13:02 ` Grazvydas Ignotas
2012-06-26 14:34 ` Alan Stern
2012-06-26 15:01 ` Tomi Valkeinen [this message]
2012-06-26 15:11 ` Alan Stern
2012-06-25 12:33 ` Jassi Brar
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=1340722875.24530.66.camel@deskari \
--to=tomi.valkeinen@ti.com \
--cc=andy.green@linaro.org \
--cc=jaswinder.singh@linaro.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mythripk@ti.com \
--cc=n-dechesne@ti.com \
--cc=notasas@gmail.com \
--cc=rjw@sisk.pl \
--cc=rnayak@ti.com \
--cc=stern@rowland.harvard.edu \
/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