By using nmcli, users who don't use a systemd based distribution (Gentoo etc.),
can run the sleep script manually, or hook it up to their service manager manually.
This also removes the forced restart if people willingly disabled NetworkManager.
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io>
See: https://github.com/jakeday/linux-surface/issues/574
As long as that issue exist, and noone of us understands how to work
with HID descriptors and fix them, replace the file with the one from
MSHW0137 which is confirmed to be working properly.
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io>
On Surface Book 2 it is not possible to archive stable S0ix while bluetooth is
enabled but no device is connected. Either S0ix fails completely, or the
residency is pretty bad. When bluetooth is disabled, or a device such as the pen
is connected, S0ix works fine and residency is great again.
By disabling bluetooth when no device is connected, we get proper S0ix in all
situations. And since no device is connected, the reset won't really matter.
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io>
This commit will update suspend.patch for 4.19
Backported these two patches:
- torvalds/linux@4eaefe8c62
(nvme-pci: Allow PCI bus-level PM to be used if ASPM is disabled)
- torvalds/linux@accd2dd72c
(PCI/ASPM: Add pcie_aspm_enabled())
on top of these patches that are already backported by commit
qzed/linux-surface@e8a3d85b22
(Update NVMe part of suspend.patch):
- torvalds/linux@d916b1be94
(nvme-pci: use host managed power state for suspend)
- torvalds/linux@1a87ee657c
(nvme: export get and set features)
- torvalds/linux@d6135c3a1e
(nvme-pci: Sync queues on reset)
Tested and confirmed that suspend is working on Surface Book 1 with
THNSN5512GPU7 TOSHIBA NVMe SSD which has issue resuming from suspend
with PCI bus-level PM.
Link to issue: https://github.com/jakeday/linux-surface/issues/123
(Surface Book with Performance Base: NVMe SSD breaks suspend (s2idle))
- ipts: fix crash caused by calling ipts_send_feedback() repeatedly
(v2-ipts-fix-crash-caused-by-calling-ipts_send_feedback-.patch from kitakar5525/ipts-fix-crash)
- i915: ipts: add destroy_doorbell() when disabling ipts guc submission
(https://github.com/jakeday/linux-surface/issues/544#issuecomment-517626511)
- IPTS: Enable debug prints (qzed/linux-surface@a5e6433)
- IPTS: Do not call intel_ipts_cleanup on suspend (qzed/linux-surface@f52dae4)
- IPTS: Add device link for PM (qzed/linux-surface@cf887d8)
- Fix RCS0 GPU hang on module removing
(0001-Fix-RCS0-GPU-hang-on-module-removing.patch from kitakar5525/linux-surface-patches)
Using the old script I regulary had the problem, that after resuming
from suspend (or hibernate) the wifi would just break. The only way
to fix it was to restart network manager, or disable it in the GNOME
network settings.
I am not a 100% sure *why*, but this change greatly improved the wifi
stability after resume. I am running this for like 5 days now and
didn't see the wifi breaking once. I suppose, that `modprobe` vs
`modprobe -i` is what makes the difference.
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io>
Integrate the changes discussed in [1] as proposed by @kitakar5525 in
[2]. The IPTS suspend/resume mechanism should work without the need for
unloading/reloading the corresponding modules, so we comment-out and
update the workaround and will handle any issues coming from that via
the IPTS drivers. The workaround is not completely removed yet as want
to provide an easy-to-apply temporary fix in case anything goes wrong.
[1]: https://github.com/jakeday/linux-surface/issues/544
[2]: https://github.com/jakeday/linux-surface/issues/544#issuecomment-519126757
Note:
NVMe part will be merged into Linux 5.3. Remove the part in
0002-suspend.patch when it arrives.
For 5.2
- (Reverted NVMe part of 0002-suspend.patch to apply following patch set)
- nvme: export get and set features · torvalds/linux@1a87ee6torvalds/linux@1a87ee6
- nvme-pci: use host managed power state for suspend · torvalds/linux@d916b1b
torvalds/linux@d916b1b#diff-bc4c090f021c046a7d256a3fcf86b7da
For 4.19, this patch is also applied
- nvme-pci: Sync queues on reset · torvalds/linux@d6135c3
torvalds/linux@d6135c3#diff-bc4c090f021c046a7d256a3fcf86b7da
See
- Surface Book with Performance Base: NVMe SSD breaks suspend (s2idle) · Issue jakeday#123 · jakeday/linux-surface
jakeday#123
Revert a3a3ed3: "updating 4.19 patches to fix touch and suspend".
Calling intel_ipts_cleanup during suspend causes destroy_doorbell to
fail. Furthermore, removing intel_ipts_cleanup from suspend does not
seem to cause any issues on the Surface Book 1 and 2, and the
introduction of the device link in the previous commit may have fixed
some of the edge-cases/race conditions that may have made this call
necessary in the past. If any issue arises from this, we will deal with
it later in a more subtle way.
See https://github.com/jakeday/linux-surface/issues/544 for an
exhaustive discussion on this.
The newer surface devices Pro 4 and up do not define _PRW to specify
which GPE interrupt belongs to the lid. Thus they may not be marked as
wake-up sources automatically, so we have to do this manually.