Re: Solving suspend-level confusion

[David Brownell <david-b@pacbell.net>]

On Saturday 31 July 2004 10:01, Oliver Neukum wrote:
> 
> > So suspend-to-RAM more or less matches PCI D3hot, and
> > suspend-to-DISK matches PCI D3cold.  If those power states
> > were passed to the device suspend(), the disk driver could act
> > appropriately.  In my observation, D3cold was never passed
> > down, it was always D3hot.
> 
> Maybe a better approach would be to describe the required features to
> the drivers rather than encoding them in a single integer. Rather
> like passing a request that states "lowest power level with device state
> retained, must not do DMA, enable remote wake up"

For PCI devices this is mostly defined by the parameter that says
what PCI power state to enter.  Even still-common "legacy" PCI
devices can basically fit into those definitions (though they may
not handle "low power" states other than "off").

Enabling remote wakeup is somewhat orthogonal.  Network
drivers have separate Wake-On-LAN calls, but that stuff should
arguably be part of the driver model PM framework.  Much of
the Linux PM work seems to be limited to "suspend when laptop
lid shuts, resume when it opens" ... which is a necessary start (one
that doesn't work universally yet either!) but not sufficient.


> [..]
> > Though the PM core doesn't cooperate at all there.  Neither the
> > suspend nor the resume codepaths cope well with disconnect
> > (and hence device removal), the PM core self-deadlocks since
> > suspend/resume outcalls are done while holding the semaphore
> > that device_pm_remove() needs, ugh.
> 
> Shouldn't we deal with this like a failed resume?

That was the first place I kept running into the deadlocks,
and I had to rewrite chunks of the OHCI driver to avoid
them.  The problem is that PM core uses a semaphore to
protect list membership, rather than a spinlock, and
that the semaphore is also trying to protect against more
than one thing at a a time.

- Dave