Re: Nested suspends; messages vs. states

Alan Stern
2005-03-23T21:08:57Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2109 bytes --]

On Tue, 22 Mar 2005, Patrick Mochel wrote:

> On Tue, 22 Mar 2005, Alan Stern wrote:
>
> > When per-device locking gets added to the driver model, this can be
> > handled by making the PM core lock all devices before starting STR and
> > unlock them all after waking up. Then any user process trying to resume a
> > device in the middle will block until the system is fully awake.
>
> That's not a sane design. You do not want 1 function locking and another
> unlocking. That's trouble waiting to happen. We can solve that problem
> today using a single semaphore to synchronize all PM calls. If a runtime
> PM request comes in while a system PM request is being processed, that
> process will block until the semaphore is dropped (when the system is
> resumed). It will serialize all runtime PM calls, but those are not
> performance-critical operations, and it shouldn't matter too much.

1 function locking and another unlocking? Not being aware of all the
details of the system-power-management code, I kind of assumed STR looked
something like this:

void suspend_to_ram()
{
suspend all devices
turn off main power
/* Zzzz... */
resume all devices
}

So what's wrong with changing it into:

void suspend_to_ram()
{
lock all devices
suspend all devices
turn off main power
/* Zzzz... */
resume all devices
unlock all devices
}

I agree that your single-semaphore idea would also work to prevent
unwanted resumes during a system sleep. But it doesn't protect against
the possibility of devices being removed or added while the PM core is
traversing its lists. Locking does protect against that -- or rather, it
will once the mechanisms have been added to the driver model core.

Now maybe the list traversal doesn't need protection. Something like
"Always suspend next the most recently added device that hasn't already
been suspended" would probably work okay. But given that during a system
sleep transition the PM core is supposed to be in control of all devices
for the entire time they are suspended, doesn't it make sense to have it
lock them?

Alan Stern