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

[Robert R. Howell]

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.

Bob Howell

> I must admit I never try hibernation myself, in experience it tends to
> have more issues then regular suspend/resume and there are already enough
> other issues to worry about on Bay and Cherry Trail based devices.
> 
> But if it works on the T100TA and 02e45646d53b broke it then I will
> try to fix this, I've a T100TA myself. Currently my T100TA is at my
> local hackerspace, so I will not have access to it until coming Friday.
> 
> Regards,
> 
> Hans
>