On Mon, 2004-11-01 at 19:06 -0700, David Brownell wrote: > On Monday 01 November 2004 17:35, Benjamin Herrenschmidt wrote: > > > > What we need for APM is freeze. > > OK, then so far as I'm concerned there's no longer > any question about _needing_ "freeze". > > Should that just be a new suspend_state_t value Hrm... not sure what we ever called suspend_state_t ... I need to dig Pavel proposals. The fact that all suspend() callbacks imply freeze, which is a drivers state, makes me think that freeze is just what ... suspend() means. That is, we can get rid of the "freeze" semantic altogether if we consider that the pm_message contains a suggested "abstract" power state. suspend with state "on" would mean freeze. That is, the pm_message would contain a device power state (on, standby, sleep) and flags (freeze, apm_request, acpi_request, ... etc... ) Freeze can either be always there & implicit in which case we don't need a flag, or we can decide to use the same suspend() callback for user-triggered auto-resume PM and thus have an explicit freeze flags that get passed on system PM and not on user-triggered calls (which can make sense, in some case, the user knows it won't use a given subsystem for some time, and it's efficient then to have a "generic" way to trigger the local PM policy) Ben;
