Re: Solving suspend-level confusion

[Benjamin Herrenschmidt]

On Sun, 2004-08-01 at 10:41, David Brownell wrote:
> On Saturday 31 July 2004 10:01, Oliver Neukum wrote:
> > 
> > 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"
> 
> A pointer to some sort of struct could be generic and typesafe;
> better than an integer or enum.

Well... if it gets that complicated, drivers will get it wrong...

I'm pretty sure that in real life, drivers only care about 2 states
at this point, which is the ones needed for suspend to disk and suspend
to RAM, the later doing a D3. An assitional "standby" state could be
added later if we want.

If we really want to separate the system "target" state from the device
state, then we could indeed define a structure, but I doubt this is necessary,
I think we can get everything working with the current scheme by just slightly
adjusting the constants to properly differenciate the 2 above defined system
states.

The only thing we need to make sure of at this point is that drivers ignore
states they don't understand so we keep some flexibility to extending the list
of states.

Part of the confusion at this point is that we are playing with 2 different
concepts, which are the driver operating state and the device power state.

System suspend wants all drivers to suspend (freeze activity so that a
consistent state of the driver is kept in memory). It may or may not
be followed by a device power down.

Dynamic per-device power management would alter the device power state,
but without putting the driver into a suspended state (actually, the driver
itself would be responsible to turning the device back on as soon as some kind
of request comes in).

I think we don't need at this point to provide hooks or abstractions to
represent these. Doing so would break everything, we don't need to do it
at this point, we can at least get something reasonably working with our
current scheme. The device power state policy can remain under driver
control imho and don't need to be abstracted. At least not now. Let's get
things working with what we have, for system suspend, and drivers who want
to do dynamic PM can implement it locally.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/