cb22 / macbook12-spi-driver

WIP input driver for the SPI touchpad / keyboard found in the 12" MacBook (MacBook8,1 + MacBook9,1)
GNU General Public License v2.0
298 stars 103 forks source link

ACPI wakeup not working #4

Open cgutman opened 7 years ago

cgutman commented 7 years ago

I tried getting this to work during my work on #2 but never managed it. I called device_init_wakeup(dev, true) in probe(), but I never seemed to get any GPEs when the system was suspended. /proc/acpi/wakeup indicated that the GPE was enabled for wakeup.

Because we need to re-enable SPI after resume, maybe we're powering down certain devices that should be left on in S3 to support wakeup?

l1k commented 7 years ago

It's possible that wakeup isn't signalled with the GPE, but via I2C to the SMC, so maybe this needs to be fixed in drivers/hwmon/applesmc.c.

l1k commented 7 years ago

This patch popped up on linux-acpi this morning and looks like it could be related, maybe the GPE mask needs to be fixed up?

http://marc.info/?l=linux-acpi&m=147422516722501&w=2

cgutman commented 7 years ago

I tried waking the machine via clicking the trackpad and checking what Windows claimed woke the machine, and the result seems to only add to the confusion.

Windows (via powercfg /lastwake) claims the system was woken by the ACPI Lid when clicking the trackpad to wake the machine. When waking the PC via a USB keyboard, it correctly identified the keyboard as the wake source. Actually waking the PC via the lid also results in the system claiming the lid woke it up.

cgutman commented 7 years ago

This might be related to _OSI(Darwin) it seems. When I pass acpi_osi="Windows 2012" on the kernel command line, it wakes perfectly via the trackpad or keyboard.

@cb22 can you confirm this?

l1k commented 7 years ago
This might be related to _OSI(Darwin) it seems. When I pass acpi_osi="Windows 2012" on the kernel command line, it wakes perfectly via the trackpad or keyboard.

Hm, according to the DSDT, wakeup is signaled with GPE 0x6F and the only difference that I can find between OSDW and !OSDW is that for Darwin the "deepest power system sleeping state that can be entered while still providing wake functionality" is S4, wheras for !Darwin it's S3.

Windows (via powercfg /lastwake) claims the system was woken by the ACPI Lid when clicking the trackpad to wake the machine. When waking the PC via a USB keyboard, it correctly identified the keyboard as the wake source. Actually waking the PC via the lid also results in the system claiming the lid woke it up.

Pin 26 on the trackpad connector signals a lid status change to the SMC. Looks like the trackpad board contains the hall effect sensor to detect lid status. Perhaps when clicking the trackpad, this signal is muxed onto that pin?