applespi: Disable/re-enable gpe interrupt on suspend/resume.

[roadrunner2]

At least on MBP13,3 the keyboard is non-responsive after the resume otherwise.

[Dunedan]

@roadrunner2: So suspend is working on your MacBookPro13,3? If yes, then the NVMe controller in the MacBookPro13,1 and MacBookPro13,2 should be the only component preventing suspend to work on these models.

[cb22]

@Dunedan yeah, to the best of my knowledge with my MacBook9,1; it's really only the NVMe controller that's blocking things. Suspend / resume when booting from USB storage without the NVMe initialized seems to work perfectly.

There's a bunch of discussion at #2 about getting the NVMe controller to behave. Basically what I figured out was that the Apple driver sends a custom command to the NVMe controller to prepare it for shutdown (or put it in a low power sleep mode - LPSR) and this seems to be the key in making it behave properly when suspended. Although this could be a complete red herring.

[cb22]

Also interestingly enough, it seems this behaviour differs between versions. On the Macbook9,1 it's not needed for the keyboard / mouse to work on resume.

[roadrunner2]

@cb22 Yes, from the discussions in #2 I figured this wasn't an issue on the MacBook's; but at the same time, I figured disabling the interrupt makes sense anyway, since the docs for dev_pm_ops state that generally the device must be quiescent after subsystem-level @suspend() has returned.

@Dunedan I'm still working on suspend/resume, but currently the following are needed for it to work reliably:

• Need to blacklist the snd_hda_intel driver - otherwise pulseaudio etc hang during suspend
• Need to unbind/rebind the usb devices across suspend - otherwise the xhci driver has errors talking to the usb devices
• the touchbar doesn't wake up after resume - at the usb level everything is fine, i.e. the commands are successfully sent, but the touchbar stays dark and doesn't respond to touches. I'm guessing something special is needed on suspend and/or resume, but will need traces from MacOS (still can't get my VM instance to recognize the iBridge device 😞 )
• Need to unplug the power - otherwise it appears to wake up the laptop again within a couple seconds.
• The lid switch is a bit hokey - can suspend once by closing, and wake by opening, but after that any suspend (e.g. via systemctl suspend or gnome's power-button) gets woken within a couple seconds unless the lid is disabled from /proc/acpi/wakeups.

[Dunedan]

the touchbar doesn't wake up after resume - at the usb level everything is fine, i.e. the commands are successfully sent, but the touchbar stays dark and doesn't respond to touches. I'm guessing something special is needed on suspend and/or resume, but will need traces from MacOS (still can't get my VM instance to recognize the iBridge device 😞 )

I got something which might be the key. MacOS sends a packet, which contains "DRLC" two times before each suspend and once or twice whenever it wakes up again. Check the attached traces for more information: touchbar-suspend.zip

[roadrunner2]

@Dunedan Thanks for the info. Since this about the touchbar, it might be better to continue this discussion on roadrunner2#3.

[jacooba]

@roadrunner2 @Dunedan I'm wondering if this might be helpful to someone with more experience than me for a wake solution:
https://aur.archlinux.org/cgit/aur.git/tree/macbook-wakeup.service?h=linux-macbook

[atyshka]

@roadrunner2, having fixed the keyboard suspend bug does the display come on? If that’s fixed is then is the computer usable after closing and opening the lid?

[roadrunner2]

@atyshka You don't mention what model you have, so I can only give you generic info: AFAIK, suspend/resume works on MB9,1 and later; on MB8,1 there's an open issue about the keyboard being unresponsive after resume; on MBP*,3 suspend/resume generally works, at least as long as you're not using external displays, but not on other MBP's due to a problem with NVMe driver. When I say "works", yes, this would mean the display comes on, at least the internal one.

[atyshka]

@roadrunner I’m not sure what number lthis corresponds to but I have a 15” 2016 pro model with gpu.

[roadrunner2]

@atyshka That sounds like you have the MBP13,3 then (under Linux see also cat /sys/class/dmi/id/product_name). I have the same model, and have found that when using the dGPU (AMD) resume indeed doesn't work; but things work (reasonably) well when using the iGPU (which I do when not using an external monitor because of the significant power savings) - for details on how to switch to the iGPU see my gist.

[anyaion]

@roadrunner2 Is suspend/resume working on MBP 14,1 with Intel iGPU? that's the only breaking bug preventing me from dual boot.

[roadrunner2]

On models with the Apple NVMe controller (which includes all *,1 and *,2 models) the disk does not wake up correctly - see Dunedan/mbp-2016-linux#37 .

[JeremiahCornelius]

I fixed my 14,1 for suspend/resume. This is as simple as a setting in the PCI driver, for the nvme storage.
cat 0 > /sys/bus/pci/devices/0000:01:00.0/d3cold_allowed

This needs to be done as root, sudo won't allow access on Ubuntu 19.xx. I wrote a simple script and a systemd wrapper for startup - depends multiuser.

I suspect this may work for other modern MBP models, prior to T2-chip introduction. You'll want to use lspci to determine the correct pci device for your specific model.

[JeremiahCornelius]

These fixes work like a charm under Ubuntu/Pop_OS! 19.04 and 19.10 beta.

/etc/systemd/system/fix_sleep.service

# systemd oneshot service to set sleep boolean on Apple Macbook Pro disks
# Original by Pier Lim. Posted at https://kerpanic.wordpress.com/2018/03/13/apple-keyboard-get-function-keys-working-properly-in-ubuntu/

    [Unit]
    Description=Job that disables sleep from stopping nvme hardware on MBP
    
    [Service]
    ExecStart=/sbin/fixsleep
    Type=oneshot
    RemainAfterExit=yes

    [Install]
    WantedBy=multi-user.target

/sbin/fixsleep

#!/bin/bash
/bin/echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed

[willpanderson]

Ive tried imputing the files on my Mac-same one as yours and while on opening the lid, it aloows me to log in but then it goes dead.

[JeremiahCornelius]

Did you confirm output of lspci to identify the right device under /sys/bus/pci/devices?
The symptoms you report were exactly those mine exhibited, prior to making the change.

Before starting these with systemd services, you can test this from the terminal, issuing the command:
# echo 0 > /sys/bus/pci/devices/0000\:01\:00.0/d3cold_allowed
This needs to be executed as a root login, at least on Ubuntu systems, and not just sudo.

[yerke]

I can confirm that running echo 0 > /sys/bus/pci/devices/0000\:00\:1c.0/d3cold_allowed as root allowed my 13,1 to wake up from hibernation. I chose the first PCI device from the list:

root@ubuntu:~# lspci | grep PCI
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1d.1 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #10 (rev f1)
04:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] (rev 02)
05:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)

[JeremiahCornelius]

I can confirm that running echo 0 > /sys/bus/pci/devices/0000\:00\:1c.0/d3cold_allowed as root allowed my 13,1 to wake up from hibernation. I chose the first PCI device from the list:

This is great. I think it's the first confirmation of this working on another model than my 14,1!

[omnibrain]

Does not work on my 9,1 unfortunately... 😞

[JeremiahCornelius]

Does not work on my 9,1 unfortunately... disappointed
That's an old machine. Is it SATA disk?

[omnibrain]

Not that old, the 2016 12“ MacBook: https://wiki.archlinux.org/index.php/Mac#April_2016_12"_-_Version_9,1

Has an NVMe disk.

[JeremiahCornelius]

Nice. Keeping the Apple designations straight is a tasking enterprise!

[pennz]

I can confirm that running echo 0 > /sys/bus/pci/devices/0000\:00\:1c.0/d3cold_allowed as root allowed my 13,1 to wake up from hibernation. I chose the first PCI device from the list:

root@ubuntu:~# lspci | grep PCI
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1d.1 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #10 (rev f1)
04:00.0 PCI bridge: Intel Corporation DSL6540 Thunderbolt 3 Bridge [Alpine Ridge 4C 2015] (rev 02)
05:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
05:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)

Hi @yerke,
In my MBP 14,1, lspci can give me this information

00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev ff)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1d.1 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #10 (rev f1)
00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO UART Controller #0 (rev 21)
00:1e.3 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO SPI Controller #1 (rev 21)
00:1f.0 ISA bridge: Intel Corporation Intel(R) 100 Series Chipset Family LPC Controller/eSPI Controller - 9D4E (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Mass storage controller: Apple Inc. S3X NVMe Controller (rev 12)
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4350 802.11ac Wireless Network Adapter (rev 05)
03:00.0 Multimedia controller: Broadcom Inc. and subsidiaries 720p FaceTime HD Camera
...

so 01:00.0 should be the NVM. I can fix my suspension problem just disable d3_cold for 01:00.0.
And I found this info for PCI Express Root Port:

The PCI Express Root Port functions the same way as a regular PCI Express port, with the additional function of monitoring the interconnect hierarchy of the PCI ports. This function includes tracking the interconnect bandwidth and making sure that the PCI port hierarchy is functioning properly.