On Tue, 2004-11-02 at 13:07 +0100, Pavel Machek wrote:
> Hi!
>
> Updated proposal, if it looks okay, I'll submit it as a patch for
> Documentation/power/devices.txt.
>
> pm_message_t meaning
>
> pm_message_t has two fields. event ("major"), and flags. If driver
> does not know event code, it aborts the request, returning
> error. Unknown flag should be non-fatal.
Should it return an error ? If we want to add new events, like pre/post
suspend or whatever else, do I need to fix all drivers ?
Also, we need to add pm_message_t argument to resume.
> Event codes are:
>
> ON - no need to do anything except special cases like broken hw
> FREEZE - stop dma and interrupts, and be prepared to reinit hw from scratch
> SUSPEND - like FREEZE, but also put hardware into low-power state
I think that
1) ON is useless. FREEZE is the logical semantic. It doesn't harm to
FREEZE on reboot/halt, and it can even be useful since kexec uses that
too.
2) Keep STANDBY (or IDLE) event. Even if nobody cares at this point,
let's keep it. Handhelds will care. It's a "light" suspend state and we
may even want to add several levels of STANDBY in the future. By having
it defined here, the intend is made clear at least
> All events are:
We should be clear about the semantics of the events before listing them
with strange explanations :)
Something like:
All events require the driver the stop operations. That means stop
accepting upstream requests, the actual policy of what to do with them
beeing specific to a given driver. It's acceptable for a network driver
to just drop packets while a block driver is expected to block the queue
so no request is lost. (Use IDE as an example on how to do that).
Their are different in what power state they imply for the device (and
the system). FREEZE requires no power state change, and it's expected
for drivers to be able to quickly transition back to operating state.
STANDBY and SUSPEND are defined arbitrarily as "light sleep" low power
and "deep sleep" low power. The later is what will be used for things
like laptop S3 sleep, or more generally suspend-to-ram. The former is
currently a "placeholder" for use to imlement lighter dozing modes,
typically for handheld devices.
<Here add the resume events too>
Some drivers may need to deal with special cases based on the actual
type of suspend operation beeing done at the system level. This is why
there are flags.
<now, define the flags, then what they mean, not the events then the
flags>
> Apm standby -- prepare for APM event. Theoretically, drivers do not
> need to do anything. In practice, it is very good idea to quiesce
> devices. event = FREEZE, flags = APM_STANDBY
NO, it is NOT a good idea to put the HW in low power state. Some BIOSes
will be very upset by that. It's ok to use that flag to deal with "known
broken" BIOSes that fail to quiesce a known device and do it there, but
the generic case is to NOT put the device into a low power state.
> Apm suspend -- same as APM_STANDBY, but it we should probably avoid
> spinning down disks. event = FREEZE, flags = APM_SUSPEND
Same as above. Some trial & error will probably be needed for those APM
states anyway.
> System halt -- nothing is needed except in very rare cases. event
> = ON, flags = SYSTEM_HALT.
Check what kexec is using. Either that or reboot. It's good to quiesce
the driver imho. Disk want to flush caches/spindown for safety.
> System reboot -- nothing is needed except in very rare cases. event
> = ON, flags = SYSTEM_REBOOT
>
> System shutdown -- at least disks need to be spun down, or data is
> lost. On non-broken hardware, nothing is needed. event = ON, flags =
> SYSTEM_SHUTDOWN
Same as above
> Kexec -- turn off DMAs and put hardware into some state where new
> kernel can take over. event = FREEZE, flags = KEXEC
Ok, you define a different state for kexec that reboot... why not...
> Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake
> may need to be enabled on some devices. This actually has at least 3
> subtypes, system can reboot, enter S4 and enter S5 at the end of
> swsusp. event = ON, flags = SWSUSP and one of SYSTEM_REBOOT,
> SYSTEM_SHUTDOWN, SYSTEM_S4
event = ON ? Hrm... this is a power down... we need at least to flush the
disk caches & spin them down ... but yes, even can be ON... though as I
wrote earlier, I'd rather ignore the "ON" and always use FREEZE...
> Suspend to ram -- put devices into low power state. event = SUSPEND,
> flags = SUSPEND_TO_RAM
>
> Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put
> devices into low power mode, but you must be able to reinitialize
> device from scratch in resume method. This has two flavors, its done
> once on suspending kernel, once on resuming kernel. event = FREEZE,
> flags = DURING_SUSPEND or DURING_RESUME
Ok.
> Device detach requested from /sys -- deinitialize device; proably same as
> SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
> = FREEZE, flags = DEV_DETACH.
I think it's wanting to detach a device from the driver at runtime,
which imho is just a remove() method ... but Patrick will confirm
> System fully on -- device is working normally; this is probably never
> passed to suspend() method... event = ON, flags = 0
Ok, looks good except for my few comments, _and_ I don't like your
naming of the flags :) but that's a matter of taste... oh well...
Ben.
