Thread (1 message) 1 message, 1 author, 2011-06-12

Re: calling runtime PM from system PM methods

From: Rafael J. Wysocki <hidden>
Date: 2011-06-12 18:27:09

On Sunday, June 12, 2011, Alan Stern wrote:
On Sun, 12 Jun 2011, Rafael J. Wysocki wrote:
quoted
quoted
Basically, I think what Rafael was saying before referred to the 
general case, where you don't know anything about the subsystem and 
can't afford to make assumptions.  But in the real world you'll be 
writing a driver for a particular subsystem and you'll know how that 
subsystem works.  If the subsystem permits runtime PM calls to be 
nested within the system PM routines, feel free to go ahead and use 
them.
But then we get the problem that user space may echo "on" to the
device's "control" file in sysfs and the whole clever plan basically goes
south.
That would indeed be a problem if we used pm_runtime_suspend() in the
system suspend code.  But it doesn't prevent us from calling
pm_runtime_resume() during system suspend.
I agree.  Moreover, calling pm_runtime_resume() from a .prepare() callback
is actually fine, because it makes .runtime_resume() run before .suspend()
and .suspend_noirq().  But if .runtime_resume() is run between .suspend()
and .suspend_noirq(), that may lead to some trouble, again, depending on
the subsystem (or PM domain) involved.

Also, if a subsystem calls pm_runtime_resume() in one of its system suspend
callbacks (e.g. .prepare()), that's pretty much OK, because the subsystem
is basically responsible for making things work at this point.  However, if
a driver does that, it's kind of like saying "here I'm smarter than the
subsystem and I know better".

Unfortunately, platform drivers deal with a dumb subsystem, so they have
the right to think so, but that's not the case in general.

Thanks,
Rafael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help