Attention is currently required from: Martin Roth, Paul Menzel.
5 comments:
Commit Message:
Please describe the problem (summarize the bug report). […]
Added a short generic description.
A little extra detail. On Chrome OS, in certain cases, we use alarms >24 hours. Linux will then refuse to enter suspend with the dmesg error:
[ 159.041047] rtc_cmos 00:01: Alarms can be up to one day in the future
A device (laptop) that can't enter suspend will either drain the battery, or on Chrome OS, shut down the system after a certain number of retries.
Patch Set #2, Line 12: This is a mirror of commit 041fcf59025bb1801828441e09b2f56b48e12fdc made
Please abbreviate the commit hash and add the summary: […]
Done
Patchset:
Also, the test I ran successfully woke up the device after sleeping for 48 hours:
[ 565.025215] ACPI: Preparing to enter system sleep state S3
...
[ 565.037262] PM: Timekeeping suspended for 172799.695 seconds
...
[ 565.042405] ACPI: Waking up from system sleep state S3
File src/soc/amd/stoneyridge/acpi.c:
Patch Set #2, Line 86: fadt->mon_alrm = 0;
Excuse my ignorance, but is `mon_alrm` not needed, or at offset 0?
It's looks like this is not supported on the HW, hence remains 0 (read: doesn't exist).
fadt->day_alrm = 0x0d;
fadt->mon_alrm = 0;
For amd/cezanne defines are used (Ib6c3a01084a0de33894885b47c637a292d252ed4 [1]). […]
Will do as a follow-up. I thought about just doing it here, but I need to merge this into our release branch and the changes to acpi.h will cause merge conflicts.
To view, visit change 55001. To unsubscribe, or for help writing mail filters, visit settings.