From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Grant Likely <grant.likely@secretlab.ca>,
"spi-devel-general@lists.sourceforge.net"
<spi-devel-general@lists.sourceforge.net>,
Lee Jones <lee.jones@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] spi/pl022: Enable clock in probe an use runtime_idle
Date: Thu, 3 Nov 2011 16:47:15 +0100 [thread overview]
Message-ID: <4EB2B783.7020503@stericsson.com> (raw)
In-Reply-To: <20111103141336.GN12913@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
> On Thu, Nov 03, 2011 at 02:59:53PM +0100, Ulf Hansson wrote:
>>>> @@ -2342,11 +2350,19 @@ static int pl022_runtime_resume(struct device *dev)
>>>> return 0;
>>>> }
>>>> +
>>>> +static int pl022_runtime_idle(struct device *dev)
>>>> +{
>>>> + pm_runtime_suspend(dev);
>>>> + return 0;
>>>> +}
>>>> #endif
>>>> static const struct dev_pm_ops pl022_dev_pm_ops = {
>>>> SET_SYSTEM_SLEEP_PM_OPS(pl022_suspend, pl022_resume)
>>>> - SET_RUNTIME_PM_OPS(pl022_runtime_suspend, pl022_runtime_resume, NULL)
>>>> + SET_RUNTIME_PM_OPS(pl022_runtime_suspend,
>>>> + pl022_runtime_resume,
>>>> + pl022_runtime_idle)
>>> This is an unnecessary change.
>>>
>>> The bus-level ops runtime PM ops call pm_generic_runtime_idle() when
>>> its 'runtime_idle' operation is invoked. Let's look at the code
>>> there:
>>>
>>> int pm_generic_runtime_idle(struct device *dev)
>>> {
>>> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>>>
>>> if (pm && pm->runtime_idle) {
>>> int ret = pm->runtime_idle(dev);
>>> if (ret)
>>> return ret;
>>> }
>>>
>>> pm_runtime_suspend(dev);
>>> return 0;
>>> }
>>>
>>> If the driver has a NULL runtime idle, then generic code will call
>>> pm_runtime_suspend() for the device. So, adding a runtime_idle callback
>>> to a driver to explicitly call pm_runtime_suspend() is not required.
>>>
>> You are somewhat correct. But the patch is still needed as is!
>
> No it is not required, by any means shape or form.
>
>> Reason is simply that after a probe, driver core is calling
>> pm_runtime_put_sync. This will not go through the
>> pm_generic_runtime_idle function, but directly to __pm_runtime_idle.
>
> Let's look at the code:
>
> static inline int pm_runtime_put_sync(struct device *dev)
> {
> return __pm_runtime_idle(dev, RPM_GET_PUT);
> }
>
> int __pm_runtime_idle(struct device *dev, int rpmflags)
> {
> ...
> spin_lock_irqsave(&dev->power.lock, flags);
> retval = rpm_idle(dev, rpmflags);
> spin_unlock_irqrestore(&dev->power.lock, flags);
> ...
> }
>
> static int rpm_idle(struct device *dev, int rpmflags)
> {
> int (*callback)(struct device *);
> ...
> if (dev->pm_domain)
> callback = dev->pm_domain->ops.runtime_idle;
> else if (dev->type && dev->type->pm)
> callback = dev->type->pm->runtime_idle;
> else if (dev->class && dev->class->pm)
> callback = dev->class->pm->runtime_idle;
> else if (dev->bus && dev->bus->pm)
> callback = dev->bus->pm->runtime_idle;
> else
> callback = NULL;
>
> if (callback)
> __rpm_callback(callback, dev);
> ...
> }
>
> static int __rpm_callback(int (*cb)(struct device *), struct device *dev)
> __releases(&dev->power.lock) __acquires(&dev->power.lock)
> {
> ...
> retval = cb(dev);
> ...
> }
>
> Nothing in there calls down to the _driver_ level PM ops from the core
> runtime PM code. What will happen is that this statement will assign
> the callback pointer:
>
> callback = dev->bus->pm->runtime_idle;
>
> and dev->bus->pm will be &amba_pm. Its runtime idle function will be
> pm_generic_runtime_idle. As I quoted above:
This I totally missed! You are absolutely right!
Of course the amba bus calls the generic runtime idle function.
I will re-work the patch and remove the runtime_idle function completely!
>
>>> int pm_generic_runtime_idle(struct device *dev)
>>> {
>>> const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
>>>
>>> if (pm && pm->runtime_idle) {
>>> int ret = pm->runtime_idle(dev);
>>> if (ret)
>>> return ret;
>>> }
>>>
>>> pm_runtime_suspend(dev);
>>> return 0;
>>> }
>
> This is the only way you get down to the driver-level pm->runtime_idle
> callback.
>
> Please describe what benefit having *THIS* pm->runtime_idle(dev) pointing
> at your new function:
>
>>>> +static int pl022_runtime_idle(struct device *dev)
>>>> +{
>>>> + pm_runtime_suspend(dev);
>>>> + return 0;
>>>> +}
>
> gains us over the case where pm->runtime_idle is NULL inside
> pm_generic_runtime_idle().
>
prev parent reply other threads:[~2011-11-03 15:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-21 14:08 [PATCH] spi/pl022: Enable clock in probe an use runtime_idle Ulf Hansson
2011-10-24 12:03 ` Grant Likely
[not found] ` <20111024120342.GQ8708-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-10-24 12:50 ` Russell King - ARM Linux
2011-10-24 14:58 ` Linus Walleij
[not found] ` <1319206124-17549-1-git-send-email-ulf.hansson-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
2011-10-22 16:41 ` Linus Walleij
[not found] ` <CACRpkdY2Csh58QbtnfYikr-VtYR_wDRfC2_X_+wR3OPhgTBE3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-10-24 7:38 ` Ulf Hansson
2011-11-02 14:16 ` Russell King - ARM Linux
[not found] ` <20111102141628.GG19187-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2011-11-03 13:59 ` Ulf Hansson
2011-11-03 14:13 ` Russell King - ARM Linux
2011-11-03 15:47 ` Ulf Hansson [this message]
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=4EB2B783.7020503@stericsson.com \
--to=ulf.hansson@stericsson.com \
--cc=grant.likely@secretlab.ca \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=spi-devel-general@lists.sourceforge.net \
/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).