On Tue, 2004-11-02 at 00:50 +0100, Pavel Machek wrote: > Hi! > > pm_message_t should represent distinct values at least for following: Hrm... Ok, this time I read it all before replying so I won't immediately bark at you for splitting in too many states provided you actually do the major/minor split... though I still prefer flags in case we want more than one ... > APM_STANDBY -- prepare for APM event. Theoretically, drivers do > not need to do anything. In practice, it is very good > idea to put devices into low power state. No, no low power state, that will break BIOS in most cases. > APM_SUSPEND -- same as APM_STANDBY, but it we should probably > avoid spinning down disks. Hrm... I don't fully understand the difference between APM_STANDBY and APM_SUSPEND... Can you explain in more details in what circumstances those would be called ? > SYSTEM_HALT -- nothing is needed except in very rare cases. > SYSTEM_REBOOT -- nothing is needed except in very rare cases. > SYSTEM_SHUTDOWN -- at least disks need to be spun down, or data is > lost. On non-broken hardware, nothing is needed. Add to that SYSTEM_KEXEC > SUSPEND_DISK_DOWN -- very similar to SYSTEM_SHUTDOWN, except wake > may need to be enabled on some devices. > SUSPEND_RAM -- put devices into low power state > SUSPEND_DISK_FREEZE -- 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. Ok, do we differentiate the FREEZE done for snapshotting the suspend image and the one done to the "loader" kernel just before resuming the suspend image ? Maybe we should ... I'm getting back to my flags or minor/major thing, some drivers will want to differenciate, at SUSPEND_DISK_DOWN level, wether it's a real shutdown, or an ACPI S4/5 state, though they definitely can't store any state that will be kept on resume here. > DEV_DETACH -- deinitialize device; proably same as > SYSTEM_SHUTDOWN, I do not understand this one too much. What is this ? Driver remove() method is all we need here .. no ? > FULL_ON -- device is working normally; this is probably never passed > to suspend() method... No, be need several cases of RESUME instead. > Now... How to split this? Perhaps we need major code and flags field? > If driver does not know major code, it aborts the request, returning > error. Unknown flag should be non-fatal. > > What are major codes? Probably > > ON > FREEZE > SUSPEND > > are needed. Then mapping would be > > APM_STANDBY -- major = SUSPEND, flags = APM_TO_RAM no, major = FREEZE > APM_SUSPEND -- major = SUSPEND, flags = APM_TO_DISK what is this one compared to the above ? > SYSTEM_HALT -- major = ON, flags = HALT no, FREEZE > SYSTEM_REBOOT -- major = ON, flags = REBOOT > SYSTEM_SHUTDOWN -- major = ON, flags = > SHUTDOWN > SUSPEND_DISK_DOWN -- major = ON, flags = SHUTDOWN, SUSPEND_TO_DISK same > SUSPEND_RAM -- major = SUSPEND, flags = SUSPEND_TO_RAM > SUSPEND_DISK_FREEZE -- major = FREEZE, flags = ON_SUSPENDING_KERNEL > SUSPEND_DISK_FREEZE -- major = FREEZE, flags = ON_RESUMING_KERNEL Ok, so you called them the same but with different flags :) Heh, let's get rid of the left column name completely. > DEV_DETACH -- major = FREEZE, flags = DEV_DETACH > > How does this look? [Ok, major scares me, probably it should be > event=, flags=] Agreed. Ben.
