Caroline: After suspend/resume, no touchscreen, kernel spew re: i2c_designware/atmel_mxt_ts

[bcarnes]

Caroline/UEFI Running 3.0beta2

After suspend/resume, usually lose touchscreen, and get infinite spew in dmesg of:

[41763.241110] Disabling non-boot CPUs ...
[41763.251161] WARNING: CPU: 1 PID: 7225 at kernel/kthread.c:486 kthread_park+0x5a/0x70
...
[41763.298281] ACPI: Waking up from system sleep state S3
[41764.367592] i2c_designware i2c_designware.0: controller timed out
[41764.405234] i2c_designware i2c_designware.0: timeout in disabling adapter
[41764.405259] atmel_mxt_ts i2c-ATML0001:00: __mxt_read_reg: i2c transfer failed (-110)
[41764.405263] atmel_mxt_ts i2c-ATML0001:00: Failed to read T44 and T5 (-110)
[41764.431094] i2c_designware i2c_designware.0: timeout waiting for bus ready

@reynhout - you mentioned in https://github.com/GalliumOS/galliumos-skylake/pull/2#issuecomment-502812238 that "Shutdown and suspend have been consistently good for several kernel builds on CAROLINE".

I find the above reproduces very reliably. Can you try suspending/resuming your caroline a few times, and then confirm your touchscreen still works? The whole machine will be a bit slower during all the i2c timeouts and kernel logging infinite spew.

As mentioned in #274, the quickest workaround is just "echo s2idle > /sys/power/mem_sleep", but I've been running with a nicer one with a /lib/systemd/system-sleep/atmel_mxt_ts pre/post trigger that preserves S3 deep sleep.

Wanted to make sure you could reproduce the badness before I push a fix for it...

[reynhout]

@bcarnes I can't repro this issue on CAROLINE/UEFI/3.0final.

In 20 suspend/resume cycles, I did get one instance of the kernel/kthread.c:486 warning you pasted above. Touchscreen remained solid throughout. I am triggering Suspend via the power menu, not by waiting for an idle timer. I wouldn't expect that to matter, but you never know..!

Anyway, I'll merge your PR and publish a pkg to the testing repo. Not sure why our CAROLINEs are different, but I'm sure others have the same issues you're seeing. Thanks for putting this together!

[bcarnes]

@reynhout Try doing a handful of suspend/resumes by just closing the laptop lid, then reopening it. Disable this fix, and see if the above causes you to see the i2c errors and touchscreen breakage more reliably.

[reynhout]

@bcarnes Same results for suspend-via-lid-closure:

• All suspends succeeded, with no touchscreen issues
• I frequently (maybe always) saw the kthread error and stack trace on the first suspend after reboot (30-40 lines in the log). All subsequent attempts are quiet
• As with suspend-via-power-menu, I see identical behaviour with and without the sleep script

This is on a completely fresh and default install of 3.0final, only modifications to the system are pkg updates (testing repodist enabled).

[bcarnes]

@reynhout We've noticed a few differences between our carolines so far. Which UEFI bios version are you on? (check via "sudo dmidecode")

Can you update yours to the latest MrChromebox firmware. After doing so, you should see (from dmidecode):

    Vendor: coreboot
    Version: MrChromebox-4.9
    Release Date: 01/04/2019

That might resolve some of these differences in behavior. Curious if it'll make your touchscreen across suspend/resume misbehave in the same way, and if it might also fix your caroline's audio looking for a different firmware:

On mine I see.

$ sudo hexdump -C /sys/firmware/acpi/tables/NHLT | head -2 00000000 4e 48 4c 54 4c 1a 00 00 05 0d 43 4f 52 45 76 34 |NHLTL.....COREv4| 00000010 43 4f 52 45 42 4f 4f 54 00 00 00 00 43 4f 52 45 |COREBOOT....CORE|

Note the "COREv4". Which is where the "9d70-COREv4-COREBOOT-0-tplg.bin" comes from.

On yours, you needed "9d70-CORE-COREBOOT-0-tplg.bin". Perhaps when you update, that'll get normalized also?