lkml.org 
[lkml]   [2023]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectQuestion on platform_suspend_ops::suspend_again() callback
Hi Rafael / Pavel

I work with the QC display team and help to co-maintain the MSM display
sub-system.

I had a question about the suspend_again() callback in the
platform_suspend_ops

Typical pm_suspend() callflow is like below:

pm_suspend()

->pm_suspend()
->enter_state()
-> suspend_prepare()
-> suspend_freeze_processes()
(freeze all userspace processes)
-> suspend_devices_and_enter()
-> dpm_suspend_start()
-> suspend_enter()
-> s2idle_loop
-> dpm_resume_early()
(after breaking out of loop)

-> suspend_finish()
-> suspend_thaw_processes()
(unfreeze all userspace processes)


Now, lets say while we are in s2idle() (typically in the display idle
screen use-cases) and then an interrupt fires. We will then break out of
the loop and also unfreeze() all usermode processes unless
we have a suspend_again() callback
https://github.com/torvalds/linux/blob/master/kernel/power/suspend.c#L512
due to the suspend_thaw_processes().

(ignoring the error and wakeup conditions for this discussion)

From our profiling it takes about 300ms to wakeup these usermode
processes on android (it can vary based on how many processes were
running, which OS etc).

But on an average we can can continue to remain idle for about 300ms
more if can skip the usermode process wakeup.

From the documentation of the suspend_again() also, it seems that
defining this callback would ensure we can address the interrupt and go
back to the s2idle instead of waking up usermode processes and trying
again after that.

* @suspend_again: Returns whether the system should suspend again
(true) or
* not (false). If the platform wants to poll sensors or execute some
* code during suspended without invoking userspace and most of
devices,
* suspend_again callback is the place assuming that
periodic-wakeup or
* alarm-wakeup is already setup. This allows to execute some
codes while
* being kept suspended in the view of userland and devices.
*

Questions to you:

1) We do not see anyone using this suspend_again() op currently. Has
there been any discussion about this before or are there any existing
patches in the list which demonstrate a usage? If so, can you pls point
us to those?

2) If there are no such patches, if we go ahead and add a
suspend_again() callback and post it for review, can it be considered
for acceptance?

3) If suspend_again() callback is not the way to go, can you please
suggest an alternative of how we can avoid wakeup of userspace process.

Just want to make sure that there are no reasons which we are not aware
of before attempting this.

Thanks

Abhinav

\
 
 \ /
  Last update: 2023-06-28 00:21    [W:0.029 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site