Page MenuHomeFreeBSD

acpi: Parse _S3D s2idle instead of _S255D
Needs ReviewPublic

Authored by obiwac on Feb 5 2026, 12:13 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 26, 8:45 AM
Unknown Object (File)
Sat, Mar 21, 4:42 PM
Unknown Object (File)
Thu, Mar 19, 6:49 AM
Unknown Object (File)
Thu, Mar 19, 5:12 AM
Unknown Object (File)
Mon, Mar 16, 2:22 AM
Unknown Object (File)
Wed, Mar 11, 10:59 AM
Unknown Object (File)
Wed, Mar 11, 10:05 AM
Unknown Object (File)
Mon, Mar 9, 5:36 PM
Subscribers

Details

Reviewers
olce
jkim
Summary

Currently, when entering s2idle, we are parsing the _S255D object to get the shallowest D-state supported by device, as acpi_stype_to_sstate() returns -1 for s2idle.

Instead, we should be parsing _S3D (not sure if this is the ideal solution, but it seems reasonable). Asking the SPMC for the minimum D-state constraints and honouring that does not work at least on my machine, and I'm not sure either way if "minimum" means "proper". So I think parsing _S3D is the right approach here.

Relevant document: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/07_Power_and_Performance_Mgmt/device-power-management-objects.html#s3d-s3-device-state

Sponsored by: The FreeBSD Foundation

Test Plan

I need someone with working S3 on their laptop to make sure I didn't break this (again)!

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 70473
Build 67356: arc lint + arc unit

Event Timeline

obiwac added reviewers: olce, jkim.
obiwac retitled this revision from acpi: _S225D fix to acpi: Evaluate _S3D instead of _S225D when entering s2idle.
obiwac edited the summary of this revision. (Show Details)

Ask SPMC for D-state in s2idle instead of _S255D

obiwac retitled this revision from acpi: Evaluate _S3D instead of _S225D when entering s2idle to acpi: Ask SPMC for D-state in s2idle instead of _S255D.Feb 6 2026, 5:32 PM
obiwac edited the summary of this revision. (Show Details)
obiwac edited the test plan for this revision. (Show Details)

I need someone with working S3 on their laptop to make sure I didn't break this (again)!

I can give this a try on my WIP branch in a little while, on my Framework 13" 11th gen Intel. Currently running wipbsd-n283918-87f5b3153f15 which is a bunch of WIP from main at c59a47dc6c016dff74466cecb160459980a5d782, and S3 is working.

Now running wipbsd-n284325-ae4a668b7590 which has been rebased on main as of 89aa8a94053fdd22ed716fdf424a2d10e70b3188 and includes this patch. CPU is 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz (2803.20-MHz K8-class CPU. S3 works as before.

Fix passing dev instead of handle to acpi_device_pwr_for_sleep_sxd

Remove comment about overriding next D-state, as it was confusing and was anyway explained elsewhere.

I have not looked into this yet, but I think this revision causes S0i3 entry to fail for some reason (even though power consumers should still be switched to D3). So changing status to planned changes.

even though power consumers should still be switched to D3

erm no, I totally forgot what this patch did. It is switching to whatever the minimum D-state the SPMC is asking for is. For some reason, even though we honour this, the platform doesn't suspend (maybe platform bug), but either way we should aim to enter D3. So when doing s2idle, let's just evaluate _S3D.

Don't honour SPMC min D-state. Just read _S3D as if we were entering S3.

Previous testing of the ACPI S3 path should still be valid. Fixes entering S0i3 on some platforms.

obiwac retitled this revision from acpi: Ask SPMC for D-state in s2idle instead of _S255D to acpi: Parse _S3D s2idle instead of _S255D.