3ab2b5480f
The approach sxmo_wakeafter uses is flawed because the kernel isn't obligated to pass control to it after suspend. I'm pretty sure it normally gets called when the kernel updates the system clock. Since we're waiting for some time after every suspend we're not actually using opportunistic suspend. It's much simpler to read wakeup_count to ask the kernel to wait until there's no active locks. Signed-off-by: Willow Barraco <contact@willowbarraco.fr>
36 lines
999 B
Bash
Executable File
36 lines
999 B
Bash
Executable File
#!/bin/sh
|
|
# SPDX-License-Identifier: AGPL-3.0-only
|
|
# Copyright 2022 Sxmo Contributors
|
|
|
|
# include common definitions
|
|
# shellcheck source=scripts/core/sxmo_common.sh
|
|
. sxmo_common.sh
|
|
|
|
set -e
|
|
# TODO: debugging only
|
|
set -x
|
|
|
|
while true; do
|
|
# Make sure it's fresh before checking locks, reading wakeup_count will
|
|
# block so we can't poll it here
|
|
sxmo_hook_check_state_mutexes.sh
|
|
|
|
# Reading from wakeup_count blocks until there are no wakelocks
|
|
wakeup_count=$(cat /sys/power/wakeup_count)
|
|
|
|
# If the wakeup count has changed since we read it, this will fail so we
|
|
# know to try again. If something takes a wake_lock after we do this, it
|
|
# will cause the kernel to abort suspend.
|
|
echo "$wakeup_count" > /sys/power/wakeup_count || continue
|
|
|
|
# If sxmo_suspend failed then we didn't enter suspend, it should be safe
|
|
# to retry immediately. There's a delay so we don't eat up all the
|
|
# system resoures if the kernel can't suspend.
|
|
if ! sxmo_suspend.sh; then
|
|
sleep 1
|
|
continue
|
|
fi
|
|
|
|
sleep 10
|
|
done
|