PM / Domains: Fix race conditions during boot

On Friday, November 07, 2014 07:25:08 PM Grygorii Strashko wrote:

[cut]

Quoted 9 lines

4) I've copied here comment from Rafael:

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 1 line

So, any volunteers to check and fix ~500 drivers.

Where did you get that number from?

Also please note that some bus types don't have this problem by design (e.g. PCI, as pointed to by Alan).

[cut]

Quoted 7 lines

Quoted 5 lines

Quoted 5 lines

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

Quoted 11 lines

Quoted 4 lines

Quoted 4 lines

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

Quoted 8 lines

Quoted 8 lines

And how exactly will you then power up the PM domain when CONFIG_PM_RUNTIME is unset?

Quoted 4 lines

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

Quoted 7 lines

Quoted 2 lines

Quoted 1 line

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.

Quoted 1 line

Quoted 3 lines

- 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?