All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grygorii Strashko <grygorii.strashko@ti.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Pavel Machek <pavel@ucw.cz>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes
Date: Thu, 20 Nov 2014 17:06:30 +0200	[thread overview]
Message-ID: <546E0376.3030300@ti.com> (raw)
In-Reply-To: <CAPDyKFrssg8wTr7e+EDrrgvHCndq8hcoNJb8TQGc_tt4ePpdEw@mail.gmail.com>

On 11/20/2014 03:01 PM, Ulf Hansson wrote:
> On 20 November 2014 13:17, Grygorii Strashko <grygorii.strashko@ti.com> wrote:
>> On 11/19/2014 10:54 AM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>
>>>>> Scenario 5), a platform driver with/without runtime PM callbacks.
>>>>> ->probe()
>>>>> - do some initialization
>>>>> - may fetch handles to runtime PM resources
>>>>> - pm_runtime_enable()
>>>>
>>>> Well, and now how the driver knows if the device is "on" before accessing it?
>>>
>>> In this case the driver don't need to access the device during
>>> ->probe(). That's postponed until sometime later.
>>>
>>>>
>>>>> Note 1)
>>>>> Scenario 1) and 2), both relies on the approach to power on the PM
>>>>> domain by using pm_runtime_get_sync(). That approach didn't work when
>>>>> CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
>>>>> the below patch, so that's good!
>>>>> "[PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled"
>>>>>
>>>>> Note 2)
>>>>> Scenario 3) and 4) use the same principles for managing runtime PM.
>>>>> These scenarios needs a way to power on the generic PM domain prior
>>>>> probing the device. The call to pm_runtime_set_active(), prevents an
>>>>> already powered PM domain from power off until after probe, but that's
>>>>> not enough.
>>>>>
>>>>> Note 3)
>>>>> The $subject patch, tried to address the issues for scenario 3) and
>>>>> 4). It does so, but will affect scenario 5) which was working nicely
>>>>> before. In scenario 5), the $subject patch will cause the generic PM
>>>>> domain to potentially stay powered after ->probe() even if the device
>>>>> is runtime PM suspended.
>>>>
>>>> Why would it?  If the device is runtime-suspended, the domain will know
>>>> that, because its callbacks will be used for that.  At least, that's
>>>> what I'd expect to happen, so is there a problem here?
>>>
>>> Genpd do knows about the device but it doesn’t get a "notification" to
>>> power off. There are no issues whatsoever for driver.
>>>
>>> This is a somewhat special case. Let's go through an example.
>>>
>>> 1. The PM domain is initially in powered off state.
>>> 2. The bus ->probe() invokes dev_pm_domain_attach() and then the PM
>>> domain gets attached to the device.
>>> 3. $subject patch causes the PM domain to power on.
>>> 4. A driver ->probe() sequence start, following the Scenario 5).
>>> 5. The device is initially in runtime PM suspended state and it will
>>> remain so during ->probe().
>>> 6. The pm_request_idle() invoked after really_probe() in driver core,
>>> won't trigger a runtime PM suspend callback to be invoked. In other
>>> words, genpd don't get a "notification" that it may power off.
>>>
>>> In this state, genpd will either power off from the late_initcall,
>>> genpd_poweroff_unused() (depending on when the driver was probed) or
>>> wait until some device's runtime PM suspend callback is invoked at any
>>> later point.
>>
>> if I understand things right (thanks to Russell), the Power domain may not
>>   be powered off not only in above case, but also in some cases when
>> driver is unloaded.
>>
>> AMBA bus for example:
>> static int amba_remove(struct device *dev)
>> {
>>          pm_runtime_get_sync(dev); <---------- GPD=on, dev is active, usage_count >= 1
>>          ret = drv->remove(pcdev); <----------- GPD=on, should do balancing put() to compensate all get() made by driver, usage_count == 1
>>                                    <----------- GPD=on, should do balancing get() to compensate put() in probe, usage_count == 2
>>          pm_runtime_put_noidle(dev); <---------- GPD=on, dev is active, usage_count == 1
>>
>>          /* Undo the runtime PM settings in amba_probe() */
>>          pm_runtime_disable(dev);  <---------- GPD=on, dev is active, usage_count == 1
>>          pm_runtime_set_suspended(dev); <---------- GPD=on, dev is suspended, usage_count == 1
>>          pm_runtime_put_noidle(dev); <---------- GPD=on, dev is suspended, usage_count == 0
>>
>>          amba_put_disable_pclk(pcdev);
>>          dev_pm_domain_detach(dev, true); <---------- GPD=on, dev is suspended, usage_count == 0
>
> For the generic OF-based PM domain look-up case:
> ->dev_pm_domain_detach()
>      ->genpd_dev_pm_detach() - to remove the device from the PM domain.
>         ->genpd_queue_power_off_work() - to power off unused PM domains.
>
> That does the trick, right!?

True. Thanks a lot for pointing me on right place.

regards,
-grygorii

WARNING: multiple messages have this Message-ID (diff)
From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PM / Domains: Power on the PM domain right after attach completes
Date: Thu, 20 Nov 2014 17:06:30 +0200	[thread overview]
Message-ID: <546E0376.3030300@ti.com> (raw)
In-Reply-To: <CAPDyKFrssg8wTr7e+EDrrgvHCndq8hcoNJb8TQGc_tt4ePpdEw@mail.gmail.com>

On 11/20/2014 03:01 PM, Ulf Hansson wrote:
> On 20 November 2014 13:17, Grygorii Strashko <grygorii.strashko@ti.com> wrote:
>> On 11/19/2014 10:54 AM, Ulf Hansson wrote:
>>> [...]
>>>
>>>>>
>>>>> Scenario 5), a platform driver with/without runtime PM callbacks.
>>>>> ->probe()
>>>>> - do some initialization
>>>>> - may fetch handles to runtime PM resources
>>>>> - pm_runtime_enable()
>>>>
>>>> Well, and now how the driver knows if the device is "on" before accessing it?
>>>
>>> In this case the driver don't need to access the device during
>>> ->probe(). That's postponed until sometime later.
>>>
>>>>
>>>>> Note 1)
>>>>> Scenario 1) and 2), both relies on the approach to power on the PM
>>>>> domain by using pm_runtime_get_sync(). That approach didn't work when
>>>>> CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by
>>>>> the below patch, so that's good!
>>>>> "[PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled"
>>>>>
>>>>> Note 2)
>>>>> Scenario 3) and 4) use the same principles for managing runtime PM.
>>>>> These scenarios needs a way to power on the generic PM domain prior
>>>>> probing the device. The call to pm_runtime_set_active(), prevents an
>>>>> already powered PM domain from power off until after probe, but that's
>>>>> not enough.
>>>>>
>>>>> Note 3)
>>>>> The $subject patch, tried to address the issues for scenario 3) and
>>>>> 4). It does so, but will affect scenario 5) which was working nicely
>>>>> before. In scenario 5), the $subject patch will cause the generic PM
>>>>> domain to potentially stay powered after ->probe() even if the device
>>>>> is runtime PM suspended.
>>>>
>>>> Why would it?  If the device is runtime-suspended, the domain will know
>>>> that, because its callbacks will be used for that.  At least, that's
>>>> what I'd expect to happen, so is there a problem here?
>>>
>>> Genpd do knows about the device but it doesn?t get a "notification" to
>>> power off. There are no issues whatsoever for driver.
>>>
>>> This is a somewhat special case. Let's go through an example.
>>>
>>> 1. The PM domain is initially in powered off state.
>>> 2. The bus ->probe() invokes dev_pm_domain_attach() and then the PM
>>> domain gets attached to the device.
>>> 3. $subject patch causes the PM domain to power on.
>>> 4. A driver ->probe() sequence start, following the Scenario 5).
>>> 5. The device is initially in runtime PM suspended state and it will
>>> remain so during ->probe().
>>> 6. The pm_request_idle() invoked after really_probe() in driver core,
>>> won't trigger a runtime PM suspend callback to be invoked. In other
>>> words, genpd don't get a "notification" that it may power off.
>>>
>>> In this state, genpd will either power off from the late_initcall,
>>> genpd_poweroff_unused() (depending on when the driver was probed) or
>>> wait until some device's runtime PM suspend callback is invoked at any
>>> later point.
>>
>> if I understand things right (thanks to Russell), the Power domain may not
>>   be powered off not only in above case, but also in some cases when
>> driver is unloaded.
>>
>> AMBA bus for example:
>> static int amba_remove(struct device *dev)
>> {
>>          pm_runtime_get_sync(dev); <---------- GPD=on, dev is active, usage_count >= 1
>>          ret = drv->remove(pcdev); <----------- GPD=on, should do balancing put() to compensate all get() made by driver, usage_count == 1
>>                                    <----------- GPD=on, should do balancing get() to compensate put() in probe, usage_count == 2
>>          pm_runtime_put_noidle(dev); <---------- GPD=on, dev is active, usage_count == 1
>>
>>          /* Undo the runtime PM settings in amba_probe() */
>>          pm_runtime_disable(dev);  <---------- GPD=on, dev is active, usage_count == 1
>>          pm_runtime_set_suspended(dev); <---------- GPD=on, dev is suspended, usage_count == 1
>>          pm_runtime_put_noidle(dev); <---------- GPD=on, dev is suspended, usage_count == 0
>>
>>          amba_put_disable_pclk(pcdev);
>>          dev_pm_domain_detach(dev, true); <---------- GPD=on, dev is suspended, usage_count == 0
>
> For the generic OF-based PM domain look-up case:
> ->dev_pm_domain_detach()
>      ->genpd_dev_pm_detach() - to remove the device from the PM domain.
>         ->genpd_queue_power_off_work() - to power off unused PM domains.
>
> That does the trick, right!?

True. Thanks a lot for pointing me on right place.

regards,
-grygorii

  reply	other threads:[~2014-11-20 15:06 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 15:19 [PATCH] PM / Domains: Power on the PM domain right after attach completes Ulf Hansson
2014-11-17 15:19 ` Ulf Hansson
2014-11-17 15:32 ` Russell King - ARM Linux
2014-11-17 15:32   ` Russell King - ARM Linux
2014-11-17 16:54   ` Grygorii Strashko
2014-11-17 16:54     ` Grygorii Strashko
2014-11-17 17:07     ` Russell King - ARM Linux
2014-11-17 17:07       ` Russell King - ARM Linux
2014-11-17 18:28 ` Kevin Hilman
2014-11-17 18:28   ` Kevin Hilman
2014-11-17 19:06   ` Alan Stern
2014-11-17 19:06     ` Alan Stern
2014-11-17 19:17     ` Dmitry Torokhov
2014-11-17 19:17       ` Dmitry Torokhov
2014-11-17 19:54       ` Alan Stern
2014-11-17 19:54         ` Alan Stern
2014-11-17 20:28         ` Dmitry Torokhov
2014-11-17 20:28           ` Dmitry Torokhov
2014-11-17 20:49           ` Alan Stern
2014-11-17 20:49             ` Alan Stern
2014-11-17 21:11             ` Dmitry Torokhov
2014-11-17 21:11               ` Dmitry Torokhov
2014-11-17 21:44               ` Alan Stern
2014-11-17 21:44                 ` Alan Stern
2014-11-17 22:02                 ` Dmitry Torokhov
2014-11-17 22:02                   ` Dmitry Torokhov
2014-11-17 22:12                   ` Alan Stern
2014-11-17 22:12                     ` Alan Stern
2014-11-17 22:17                     ` Dmitry Torokhov
2014-11-17 22:17                       ` Dmitry Torokhov
2014-11-17 23:28                       ` Rafael J. Wysocki
2014-11-17 23:28                         ` Rafael J. Wysocki
2014-11-17 23:26                         ` Dmitry Torokhov
2014-11-17 23:26                           ` Dmitry Torokhov
2014-11-18  0:26                           ` Rafael J. Wysocki
2014-11-18  0:26                             ` Rafael J. Wysocki
2014-11-18  2:16                             ` Rafael J. Wysocki
2014-11-18  2:16                               ` Rafael J. Wysocki
2014-11-18 14:05                               ` Ulf Hansson
2014-11-18 14:05                                 ` Ulf Hansson
2014-11-18 20:29                                 ` Rafael J. Wysocki
2014-11-18 20:29                                   ` Rafael J. Wysocki
2014-11-19  8:54                                   ` Ulf Hansson
2014-11-19  8:54                                     ` Ulf Hansson
2014-11-20  0:35                                     ` Rafael J. Wysocki
2014-11-20  0:35                                       ` Rafael J. Wysocki
2014-11-20 10:13                                       ` Ulf Hansson
2014-11-20 10:13                                         ` Ulf Hansson
2014-11-20 20:56                                         ` Rafael J. Wysocki
2014-11-20 20:56                                           ` Rafael J. Wysocki
2014-11-20 12:17                                     ` Grygorii Strashko
2014-11-20 12:17                                       ` Grygorii Strashko
2014-11-20 13:01                                       ` Ulf Hansson
2014-11-20 13:01                                         ` Ulf Hansson
2014-11-20 15:06                                         ` Grygorii Strashko [this message]
2014-11-20 15:06                                           ` Grygorii Strashko
2014-11-18 16:13                       ` Alan Stern
2014-11-18 16:13                         ` Alan Stern
2014-11-18 17:18                         ` Dmitry Torokhov
2014-11-18 17:18                           ` Dmitry Torokhov
2014-11-18 17:44                           ` Alan Stern
2014-11-18 17:44                             ` Alan Stern
2014-11-18 17:55                             ` Dmitry Torokhov
2014-11-18 17:55                               ` Dmitry Torokhov
2014-11-18 20:14                               ` Rafael J. Wysocki
2014-11-18 20:14                                 ` Rafael J. Wysocki
2014-11-18 20:04                                 ` Dmitry Torokhov
2014-11-18 20:04                                   ` Dmitry Torokhov
2014-11-18 21:03                                   ` Rafael J. Wysocki
2014-11-18 21:03                                     ` Rafael J. Wysocki
2014-11-18 21:17                                     ` Rafael J. Wysocki
2014-11-18 21:17                                       ` Rafael J. Wysocki
2014-11-18 21:02                                       ` Dmitry Torokhov
2014-11-18 21:02                                         ` Dmitry Torokhov
2014-11-18 21:58                                         ` Rafael J. Wysocki
2014-11-18 21:58                                           ` Rafael J. Wysocki
2014-11-18 21:44                                           ` Dmitry Torokhov
2014-11-18 21:44                                             ` Dmitry Torokhov
2014-11-18 22:10                                           ` Rafael J. Wysocki
2014-11-18 22:10                                             ` Rafael J. Wysocki

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=546E0376.3030300@ti.com \
    --to=grygorii.strashko@ti.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geert+renesas@glider.be \
    --cc=khilman@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=s.nawrocki@samsung.com \
    --cc=stern@rowland.harvard.edu \
    --cc=ulf.hansson@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.