What does `mcetool -searly` do if early suspend is not supported by the kernel?

asked 2018-01-14 10:22:53 +0300

marmistrz
331 ●8 ●15 ●19

updated 2018-01-14 10:29:46 +0300

I'm running SailfishOS 2.1.3.7 on my OnePlus 3. The kernel is affected by the removal of the early suspend by Google [1]

Running mcetool -searly as described in the SailfishOS cheat sheet results in no error. Still, journal doesn't mention any suspends (I was told that when the device suspends the apps to RAM, there's a relevant entry in the journal I didn't have the time to verify this manually) This suspend policy is certainly different from mcetool -sdisabled, since the battery life on the latter was significantly worse than on the former.

Hence the question: what does mcetool -searly do if the kernel doesn't support early-suspends? In particular, if it has no effect, why is no error thrown?

[1] https://plus.google.com/111524780435806926688/posts/RCV8EP3hFEm

edit retag flag offensive close delete

answered 2018-01-14 11:52:08 +0300

spiiroin
13237 ●151 ●224 ●199

moderator

Support for early-suspend devices in SFOS came during Jolla Phone development time. Since then there have been other devices that utilize the autosleep model mentioned in the linked article. The biggest differences between these two reside at the kernel driver level. From user space point of view there are some differences, but both models support/require wakelocking.

What "mcetool --set-suspend-policy=early" does is: It basically instructs mce display state machine not to release wakelock despite display being off. For both devices with early-suspend and autosleep kernels this basically means that at least one cpu core is kept "alive". For kernels without wakelock support there is no difference between "early" and "enabled".

The naming of this and related options/interfaces/etc reflects that they were developed during Jolla Phone with early suspend in mind before autosleep was on the radar. Any differences between these two models are handled "under the hood".

Also note that from mce point of view wakelocks are supported, but not required kernel feature. In devices where wakelocks are required for operational correctness they are used. While in devices where wakelocks are not supported (say, n9 + early sfos versions), inability to operate wakelocks does not signify something that should show up as error / warning.

edit flag offensive delete publish link

Comments

Thanks a lot for the swift reply! ;) Does that imply that on the devices with autosleep, mcetool -searly will prevent the applications to be suspended, as it was with early-suspend?

marmistrz ( 2018-01-14 22:08:13 +0300 )edit

@marmistrz Yes - We do not suspend individual apps/processes, so not suspending the device implies that applications are not suspended either. Or at least that is the intent ;-)

spiiroin ( 2018-01-15 11:31:58 +0300 )edit

@marmistrz Also, "suspending the device" does not necessarily mean that everything is powered down. Depending on kernel side configuration, hw capabilities, etc. some things like cellular/wlan radio comms, in-call audio handling, select sensors, and so on can function even if the main application cpu is suspended.

spiiroin ( 2018-01-15 11:51:14 +0300 )edit

What does `mcetool -searly` do if early suspend is not supported by the kernel?

1 Answer

Comments

Question tools

Stats

What does `mcetool -searly` do if early suspend is not supported by the kernel?

1 Answer

Comments

Question tools

Public thread

Stats