linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).