platform/x86: intel-vbtn: 14c200b7ca46 breaks suspend on Thinkpad X1 Tablet Gen2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Hans, all,

after upgrading to 6.7.1 or 6.6.13 (LTS), my Thinkpad X1 Tablet doesn't suspend anymore. Or, rather, it suspends, but wakes again immediately. This happens regardless of whether the keyboard is attached or not, with all ACPI wakeup triggers disabled according to /proc/acpi/wakeup.
I could identify the following commit as the culprit:

	14c200b7ca46b9a9f4af9e81d258a58274320b6f
	platform/x86: intel-vbtn: Fix missing tablet-mode-switch events

First, it's a suspiciously related patch going into both kernel versions.
Second, unloading intel-vbtn resolves the problem; machine suspends as usual.
Third, I tried modifying the patch. Commenting out the newly introduced

	/* Some devices need this to report further events */
	acpi_evaluate_object(handle, "VBDL", NULL, NULL);

resolves the problem on my machine.

I understand that the change was in for a reason, but the deeper meaning of that statement eludes me; is it possible that my model is quirky for that one?

FWIW:
- SW_TABLET_MODE is properly updated about half a second after I attach/detach/fold the keyboard during suspend with that statement commented out (but attaching/detaching/folding all wake the device, unless I also `echo Y > /sys/module/acpi/parameters/ec_no_wakeup` - but then I can't wake the tablet at all anymore).
- Folding the keyboard to the back of the device disables the keyboard.
  With that statement in (as in 6.7.1 upstream), SW_TABLET_MODE is set to 1 (correct), but reverts to 0 again after about a second (incorrect); the keyboard remains disabled.
  Without the statement, SW_TABLET_MODE remains on 1 until I flip back the keyboard to normal (expected behavior).


On a side note, I initially thought that detect_tablet_mode() in resume() is the culprit. intel_vbtn_pm_resume() is also included in the thaw callback (and I usually use hybrid suspend) and, after the patch, augmented with the detect_tablet_mode() routine.
If I understand correctly the description in [1], thaw is not really resume-/restore-like except perhaps for the corner case of failed hibernation image creation. Turns out it doesn't seem to cause the harm, but still: is intel_vbtn_pm_resume() on thaw really intended? The description says it's used to undo the changes made by the preceding freeze (including prepare), but this rather seems to match intel_vbtn_pm_complete()'s definition than intel_vbtn_pm_resume()'s... 

[1] https://www.kernel.org/doc/html/v4.12/driver-api/pm/types.html


Of course, I stand available for any debugging or further investigations; happy to do some work myself if someone can guide me through.


Cheers,
Alex




[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux