Re: [PATCH V2 1/3] PM: Introduce suspend state PM_SUSPEND_FREEZE

[Zhang Rui]

On Mon, 2013-02-04 at 15:10 +0800, Zhang Rui wrote:
> PM_SUSPEND_FREEZE state is a general state that
> does not need any platform specific support, it equals
> frozen processes + suspended devices + idle processors.
> 
> Compared with PM_SUSPEND_MEMORY,
> PM_SUSPEND_FREEZE saves less power
> because the system is still in a running state.
> PM_SUSPEND_FREEZE has less resume latency because it does not
> touch BIOS, and the processors are in idle state.
> 
> Compared with RTPM/idle,
> PM_SUSPEND_FREEZE saves more power as
> 1. the processor has longer sleep time because processes are frozen.
>    The deeper c-state the processor supports, more power saving we can get.
> 2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
>    more power saving from the devices that does not have good RTPM support.
> 
> This state is useful for
> 1) platforms that do not have STR, or have a broken STR.
> 2) platforms that have an extremely low power idle state,
>    which can be used to replace STR.
> 
> The following describes how PM_SUSPEND_FREEZE state works.
> 1. echo freeze > /sys/power/state
> 2. the processes are frozen.
> 3. all the devices are suspended.
> 4. all the processors are blocked by a wait queue
> 5. all the processors idles and enters (Deep) c-state.
> 6. an interrupt fires.
> 7. a processor is woken up and handles the irq.
> 8. if it is a general event,
>    a) the irq handler runs and quites.
>    b) goto step 4.
> 9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
>    a) the irq handler runs and activate the wakeup source
>    b) wakeup_source_activate() notifies the wait queue.
>    c) system starts resuming from PM_SUSPEND_FREEZE
> 10. all the devices are resumed.
> 11. all the processes are unfrozen.
> 12. system is back to working.
> 
> Known Issue:
> The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
> from the previous suspend state.
> Take ACPI platform for example, there are some GPEs that only enabled
> when the system is in sleep state, to wake the system backk from S3/S4.
> But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
> This means we may lose some wake event.
> But on the other hand, as we do not disable all the Interrupts during
> PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
> not available for S3/S4.
> 
> The patches has been tested on an old Sony laptop, and here are the results:
> 
> Average Power:
> 1. RPTM/idle for half an hour:
>    14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
> 2. Freeze for half an hour:
>    11W, 10.4W, 9.4W, 11.3W 10.5W
> 3. RTPM/idle for three hours:
>    11.6W
> 4. Freeze for three hours:
>    10W
> 5. Suspend to Memory:
>    0.5~0.9W
> 
> Average Resume Latency:
> 1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
>    Less than 0.2s
> 2. Freeze: (From pressing power button to screen back)
>    2.50s
> 3. Suspend to Memory: (From pressing power button to screen back)
>    4.33s
> 
> From the results, we can see that all the platforms should benefit from
> this patch, even if it does not have Low Power S0.
> 
fixed a build error when CONFIG_SUSPEND not set.
refreshed patch attached.