On Sat, 8 Aug 2009, Rafael J. Wysocki wrote:
> > We may need to be more careful here. The driver's remove method may
> > want to do some runtime PM stuff to the device before giving up
> > control. On the other hand I'm not sure what _should_ be done here, so
> > I can't suggest anything better.
>
> Hmm. Perhaps we can do something along the lines of our .probe() handling.
> Namely, call
>
> pm_runtime_disable(dev);
> pm_runtime_get_noresume(dev);
> pm_runtime_enable(dev);
>
> before and
>
> pm_runtime_put_noidle()
>
> after? Then, if the driver's or bus type's .remove() needs to resume, it will
> be able to do that right away and if it wants to suspend, it can always call
> pm_runtime_put*(), because our pm_runtime_put_noidle() won't decrease the
> usage counter below zero.
>
> At the same time we can avoid "leftover" suspends that could interfere with
> .remove() in case it needs to access the hardware.
The problem with this is that it calls pm_runtime_disable() at a time
when the driver is still supposed to be in control of the device.
Interfering with the driver's legitimate activity in this way is a bad
thing to do.
The difficulty here is that our requirements are a little
contradictory. We want to prevent all runtime PM callbacks while the
remove method is running, but we also want the remove method to be able
to carry out its own runtime PM activities.
So maybe what we really need is more like a barrier. That is,
something that will do a "get", wait for outstanding callbacks to
finish, carry out a resume if one is pending, and cancel other pending
requests. This could easily share code with pm_runtime_disable. We
should be able to use this for both probe and remove.
We will also need to be a lot more careful about handling runtime PM
during system sleep transitions. The current code runs a risk of
losing remote wakeup requests. One scenario goes like this:
1. The device sends a wakeup request, probably in the form of
an IRQ.
2. The driver fields the interrupt and tells the device to turn
off its interrupt request signal.
3. The driver calls pm_request_resume.
4. The runtime PM core carries out the resume callback.
If the core disables runtime PM before step 1 (and before we begin the
"late" stage of a system sleep, so interrupts still get delivered) then
steps 1 and 2 will succeed but step 3 will fail. The wakeup event will
be lost.
Perhaps this means we don't want to disable runtime PM during system
sleep callbacks, but instead use the "barrier" scheme.
Alan Stern
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
