On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep.
For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
Whenever I read comments like this, I think "Why is he trying to use a 10+ years old Ubuntu, or similar"?
Or do I just make way luckier buying choices? Suspend to anything has worked flawlessly out of the box for my devices since 10+ years.
Do you have a specific example of what is not an "obviously bad hardware combination choice", but yet still does not correctly support Suspend-to-RAM?
mschuster91|5 years ago
On desktops and laptops, it Usually Should Just Work (tm). The general culprits for issues are proprietary graphics and wifi drivers as well as shoddy BIOSes with broken ACPI tables, but I never had to dig this deep.
For embedded systems, the situation is more complex, as the chipset needs to support it - suspend itself is not the problem in most cases, but wakeup is - for example, the Raspberry Pi does not have a dedicated interrupt (https://github.com/raspberrypi/linux/issues/1281). If you're working with an embedded chipset, your best bet is the manufacturer, they have to deal with that in the BSP.
stragies|5 years ago
jcelerier|5 years ago
lucky you - I have a laptop (GS65) where suspend-to-ram occasionally fails to unsuspend, even on windows