Re: [PATCH] ACPI / LPSS: Don't skip late system PM ops for hibernate on BYT/CHT

From: Hans de Goede
Date: Thu Apr 18 2019 - 07:42:09 EST


Hello Robert,

On 11-04-19 21:50, Robert R. Howell wrote:
On 4/8/19 2:16 AM, Hans de Goede wrote:>

Hmm, interesting so you have hibernation working on a T100TA
(with 5.0 + 02e45646d53b reverted), right ?

Hi Hans and Kai-Heng

First, apologies for how long it took me to reply to both your inquiries.
In trying to answer them I discovered some inconsistencies in how the T100TA was
behaving on different hibernation attempts and I've been trying to sort those out.
I haven't been completely successful in that, but here's a brief summary.

Yes I do have hibernation working (at least most of the time) on a T100TA,
with 5.0 + 02e45646d53b reverted (more about that below), and with a systemd
hibernate script also described below.

Trying to be more quantitative about "most of the time" is in part want I've been
testing the last few days. I just finished a cycle of 20 hibernates/resumes
which were all successful at least in the sense that after resume internal
sound was working, along with all the other critical functions I care about
(WiFi, Bluetooth, etc.). However I have occasionally (perhaps 1 in 10 times)
seen something go wrong with sound on resume and the only way to get it
working again was to a full reboot. During the successful cycles I also
sometimes see i2c_designware or intel_sst_acpi error messages but they
don't seem to indicate an unrecoverable failure. I was hoping to sort out
what errors I was seen on the occasions where sound was lost till a reboot,
but those are rare enough I haven't been able to sort out the difference
between those and the "recoverable" errors.

Regarding the revert of 02e45646d53b, there were some code changes in
adjacent lines so a simple revert wouldn't apply cleanly to 5.0.0
but the changes were small enough that I was able to manually "merge"
the revert and the 5.0.0 changes. I have posted a patch file under
Bugzilla: <https://bugzilla.kernel.org/show_bug.cgi?id=202139>
showing what I actually did to revert 02e45646d53b for 5.0.0. As I mentioned
in an earlier message, I have NOT been able to produce a working revert of
02e45646d53b for the 5.1-rc3 kernel.

To make hibernation work on the T100 I also had to create a script
/usr/lib/systemd/system-sleep/t100_hibernate.sh which unloads various drivers
(including sound) before hibernate, then restarts them afterwords. I've inserted
it below. I'm not certain all the steps in it are still necessary, but the
intermittent failures make it very difficult to determine what is absolutely essential.

-----t100_hibernate.sh systemd script-------
#!/bin/bash
echo "Hibernate script $1 $2"
[ $2 != 'hibernate' ] && exit 0

case $1 in
pre)
echo "Going to $2..."
/sbin/modprobe -r brcmfmac
/sbin/modprobe -r hci_uart
/sbin/modprobe -r battery
/sbin/modprobe -r hid_multitouch
/usr/bin/killall pulseaudio
/sbin/modprobe -r snd_soc_sst_bytcr_rt5640
/sbin/modprobe -r snd_soc_rt5640
/sbin/modprobe -r snd_soc_sst_acpi
;;
post)
echo "Waking from $2..."
/sbin/modprobe brcmfmac
/sbin/modprobe hci_uart
/sbin/modprobe battery
/sbin/modprobe hid_multitouch
# Just load the following and it will pull in other snd modules
/sbin/modprobe snd_soc_sst_acpi
/usr/sbin/service NetworkManager restart
/usr/sbin/service wpa_supplicant restart
# The above is usually enough but occasionally sound doesn't come up properly
# and doing the following seems to restore it in those cases.
/usr/bin/killall pulseaudio
/usr/sbin/rmmod snd_soc_sst_bytcr_rt5640
/usr/sbin/rmmod snd_soc_rt5640
/usr/sbin modprobe snd_soc_rt5640
/usr/sbin modprobe snd_soc_sst_bytcr_rt5640
;;
esac
-----end of script-------------------------------

I'll send a second message with the system logs which Kai-Heng requested,
with his patch applied to 5.1-rc3.

Ok, so you have hibernation sort of working, with a bunch of hacks.

This is exactly why I usually do not spend any time on trying to get
hibernation to work.

Still since my patch is regressing things for you I will try to
take a look at this and see if I can reproduce and come up with
a fix. But this is not going to be a high priority thing for me to
work on.

In the mean time I've gone ahead and submitted my version of the
fix for the problem Kai-Heng was seeing, since that does not seem
to make your problem worse; and it will be good to get that problem
fixed.

Regards,

Hans