Page MenuHomeFreeBSD

linuxkpi: Support s2idle in `pm_suspend_target_state`
ClosedPublic

Authored by obiwac on Jul 28 2025, 11:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 3, 10:18 AM
Unknown Object (File)
Tue, Sep 30, 9:16 AM
Unknown Object (File)
Fri, Sep 26, 8:15 PM
Unknown Object (File)
Fri, Sep 26, 2:22 AM
Unknown Object (File)
Thu, Sep 25, 11:52 PM
Unknown Object (File)
Tue, Sep 16, 12:37 AM
Unknown Object (File)
Mon, Sep 15, 7:06 AM
Unknown Object (File)
Fri, Sep 12, 8:44 PM

Details

Summary

Add enum sleep_type stype parameter in power_suspend/resume event
handlers, as with the introduction of s2idle there are more than one
type of suspend.

When going to s2idle, set Linux' pm_suspend_target_state to
PM_SUSPEND_TO_IDLE instead of setting PM_SUSPEND_MEM (for S3) in all
cases. This is necessary because more recent versions of the amdgpu DRM
drivers have different paths for when entering s2idle & S0ix is
supported than S3.

Event: EuroBSDcon Devsummit 2025
Sponsored by: The FreeBSD Foundation

Test Plan

Works on AMD Framework 7040 (i.e. S0i3 is being entered correctly with these changes).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 67275
Build 64158: arc lint + arc unit

Event Timeline

obiwac planned changes to this revision.EditedJul 28 2025, 11:47 AM

I would like to make enum sleep_type (currently defined in dev/acpica/acpivar.h) generic so that it can be used on non-ACPI systems and everywhere the event handlers using power_change_fn are being used. Not 100% sure where to put this just yet though, and this needs to be changed in D48732.

In D51591#1178545, @imp wrote:

No newbus integration?

What kind of integration would you like to see with newbus? Maybe I don't understand your comment.

D52036 does the work of making sleep types generic. One that design gets the go-ahead, I will update this revision to base on top of that.

obiwac edited the summary of this revision. (Show Details)

This in general seems not to be specific to linuxkpi so maybe the title would be better to mention the eventhandler KPI update (of which linuxkpi seems to be one consumer).

I might go as far as splitting this into (a) the general event handler update and (b) improving linuxkpi?

Either way I am fine with the code changes.

I cannot comment on amdgpu, so @dumbbell could check that but if you are on a framework I assume you have tested this first hand, so...

This revision is now accepted and ready to land.Sat, Oct 4, 3:14 PM
In D51591#1208761, @bz wrote:

I might go as far as splitting this into (a) the general event handler update and (b) improving linuxkpi?

yeah, I agree. I'll split this into two revisions