From: grygorii.strashko@ti.com (Grygorii Strashko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/9] PM / Domains: Fix race conditions during boot
Date: Thu, 13 Nov 2014 22:13:03 +0200 [thread overview]
Message-ID: <546510CF.7060004@ti.com> (raw)
In-Reply-To: <7390758.7nHkBpm2Zh@vostro.rjw.lan>
On 11/13/2014 04:07 AM, Rafael J. Wysocki wrote:
> On Friday, November 07, 2014 07:25:08 PM Grygorii Strashko wrote:
>
> [cut]
>
>>
>> 4) I've copied here comment from Rafael:
>> >>>> Of course, if ->probe() is to call pm_runtime_resume() for this purpose,
>> >>>> it must take the fact that the driver's own ->runtime_resume() may be called
>> >>>> as a result of this into account.
>> Agree, that's a little bit annoying, but we are living with that for more then
>> 5 years already (I'm 3 years) - so, I am, as driver developer, expecting above behavior
>> (just walk through the drivers and you will see how many drivers expecting the same).
>>
>> So, any volunteers to check and fix ~500 drivers.
>
> Where did you get that number from?
Sry, my bad. Rechecked - found 289 occurrences of pm_runtime_enable().
Number of Runtime PM enabled drivers = at about 289 +-10%.
- headers, suspend/resume,..
+ buses like amba and spmi
>
> Also please note that some bus types don't have this problem by design (e.g. PCI,
> as pointed to by Alan).
Right. I worry about Platform bus first of all, because HW PM implementation
(at least for ARM SoCs) can be very different there.
>
> [cut]
>
>>>
>>>>
>>>> - Runtime PM (if compiled in) needs to be enabled for all devices in power
>>>> domains by default. Otherwise devices may lose power as a result for
>>>> power management of the other devices in the same domain.
>>
>> It should prevent enabling/disabling of RPM from sys_fs too.
>
> It looks like you're confusing disable/enable with auto/on. These are different
> things.
>
>>>>
>>>> - The core should try to power up domains before calling really_probe() both
>>>> for CONFIG_PM_RUNTIME set and unset, so ->probe() can always make the
>>>> "device is accessible" assumption.
>>
>> Here I'm still think that pm_runtime_get_sync() (or similar) API should work.
>> Another way, PM domain should decide what to do when the first device attached to it
>> - power up and stay powered on for example
>> (It will work if devices are attached before ->probe();
>> it will not work if devices will be attached once they've been created, but this is different
>> question)
>
> The PM domain itself can't do that. The only place that has enough knowledge
> is the code that enumerates devices (DT, ACPI or board-specific).
>
>>>
>>> And how exactly will you then power up the PM domain when
>>> CONFIG_PM_RUNTIME is unset?
>>>
>>>>
>>>> - Bus types may need to do more on top of that in their ->probe(), so the
>>>> driver's ->probe() can make that assumption too in all cases.
>>>>
>>>> Does that make sense to you?
>>>
>>
>> I would like to take the liberty to add a couple of points from me:
>> - it seems reasonable to have ability to disable Runtime PM globally from sys_fs:
>> once disabled - "get" should power on device, "put" should do nothing all the
>> time except when ->remove() is called.
>
> This is how the "power/control" file works and you can easily have this by writing
> "on" to that file for every device.
>
>>
>> - It might be reasonable to add API like pm_runtime_probe_getXXX() which will do
>> everything what standard pm_runtime_get_sync() is doing with one exception:
>> it will not call driver's .runtime_resume() callback.
>
> Use case?
This is just a different view (RFC) on your idea to call pm_runtime_get_sync()
before dev->driver is initialized
("(b) bypassing the driver callbacks somehow".
http://marc.info/?l=linux-pm&m=141505768026211&w=2)
- add some flag like dev->is_probing
- in pm_runtime_probe_get_sync() do
dev->is_probing = true;
pm_runtime_get_sync();
dev->is_probing = false;
- update 3 places in code pm_generic_runtime_resume, pm_genpd_default_save_state and
__rpm_get_callback like below (only for .runtime_resume):
+++ b/drivers/base/power/generic_ops.c
@@ -42,6 +42,9 @@ int pm_generic_runtime_resume(struct device *dev)
{
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int ret;
+
+ if (dev->is_probing)
+ pm = NULL;
Then drivers (at least platform drivers) will be able to call
pm_runtime_enable(dev);
pm_runtime_probe_get_sync(dev);
at any time they think is right (no problem with parent devices,
Power domain will be enabled, class/type/bus callback will be called,
no need to use pm_runtime_set_active()).
regards,
-grygorii
next prev parent reply other threads:[~2014-11-13 20:13 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-13 14:02 [PATCH v3 0/9] PM / Domains: Fix race conditions during boot Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 1/9] PM / Domains: Add dev_pm_domain_get|put() APIs Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 2/9] PM / Domains: Enable genpd to support ->get|put() callbacks Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 3/9] amba: Keep PM domain powered during ->probe() Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 4/9] drivercore / platform: " Ulf Hansson
2014-10-30 20:47 ` Kevin Hilman
2014-10-31 0:07 ` Dmitry Torokhov
2014-10-31 9:23 ` Ulf Hansson
2014-11-01 0:21 ` Rafael J. Wysocki
2014-10-31 9:19 ` Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 5/9] i2c: core: " Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 6/9] spi: " Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 7/9] mmc: core: Attach PM domain prior probing of SDIO func driver Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 8/9] mmmc: core: Keep PM domain powered during ->probe() " Ulf Hansson
2014-10-13 14:02 ` [PATCH v3 9/9] PM / Domains: Remove pm_genpd_dev_need_restore() API Ulf Hansson
2014-10-24 16:12 ` [PATCH v3 0/9] PM / Domains: Fix race conditions during boot Kevin Hilman
2014-10-24 16:18 ` Mark Brown
2014-10-30 20:46 ` Kevin Hilman
2014-10-30 23:56 ` Mark Brown
2014-10-31 9:16 ` Ulf Hansson
2014-11-01 0:20 ` Rafael J. Wysocki
2014-11-01 1:08 ` pm_runtime_enable() in ->probe() (was: Re: [PATCH v3 0/9] PM / Domains: Fix race conditions during boot) Rafael J. Wysocki
2014-11-01 1:14 ` Rafael J. Wysocki
2014-11-03 17:00 ` pm_runtime_enable() in ->probe() Kevin Hilman
2014-11-03 23:55 ` Rafael J. Wysocki
2014-11-03 14:03 ` [PATCH v3 0/9] PM / Domains: Fix race conditions during boot Ulf Hansson
2014-11-04 1:43 ` Rafael J. Wysocki
2014-11-04 8:20 ` Geert Uytterhoeven
2014-11-04 13:32 ` Rafael J. Wysocki
2014-11-04 8:54 ` Ulf Hansson
2014-11-04 9:05 ` Dmitry Torokhov
2014-11-04 9:24 ` Ulf Hansson
2014-11-04 13:56 ` Rafael J. Wysocki
2014-11-04 17:01 ` Ulf Hansson
2014-11-04 18:29 ` Dmitry Torokhov
2014-11-04 21:38 ` Rafael J. Wysocki
2014-11-05 8:17 ` Ulf Hansson
2014-11-04 13:52 ` Rafael J. Wysocki
2014-11-04 13:51 ` Rafael J. Wysocki
2014-11-04 16:42 ` Ulf Hansson
2014-11-07 17:25 ` Grygorii Strashko
2014-11-11 11:05 ` Ulf Hansson
2014-11-12 18:01 ` Grygorii Strashko
2014-11-13 2:07 ` Rafael J. Wysocki
2014-11-13 20:13 ` Grygorii Strashko [this message]
2014-11-13 14:05 ` Pavel Machek
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=546510CF.7060004@ti.com \
--to=grygorii.strashko@ti.com \
--cc=linux-arm-kernel@lists.infradead.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 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).