[PATCH v3 0/9] PM / Domains: Fix race conditions during boot
Rafael J. Wysocki
rjw at rjwysocki.net
Wed Nov 12 18:07:11 PST 2014
On Friday, November 07, 2014 07:25:08 PM Grygorii Strashko wrote:
> 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?
Also please note that some bus types don't have this problem by design (e.g. PCI,
as pointed to by Alan).
> >> - 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
> >> - 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
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.
> - Just opinion. For GPD, It looks like integration/design problem and may be
> it shouldn't be integrated with Runtime PM through dev_pm_ops. Instead, it
> might be better to invoke it directly from RPM core.
That I can't parse really, sorry.
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
More information about the linux-arm-kernel