Page MenuHomeFreeBSD

Suspend to idle support
Needs ReviewPublic

Authored by bwidawsk on Oct 23 2018, 10:17 PM.
Tags
None
Referenced Files
F103305453: D17675.diff
Sat, Nov 23, 8:07 AM
F103283525: D17675.diff
Sat, Nov 23, 1:32 AM
Unknown Object (File)
Tue, Nov 19, 12:42 AM
Unknown Object (File)
Mon, Nov 4, 7:08 AM
Unknown Object (File)
Oct 21 2024, 7:30 AM
Unknown Object (File)
Oct 21 2024, 6:44 AM
Unknown Object (File)
Oct 21 2024, 6:22 AM
Unknown Object (File)
Oct 17 2024, 3:02 PM

Details

Reviewers
jhb
Summary

This patch series implements suspend to idle. It was developed on github
here:
https://github.com/bwidawsk/freebsd/tree/suspend-to-idle

Suspend to idle is like s3 except instead of using ACPI to suspend and resume,
it simply idles the CPU. Please see the commit messages on github for a
description of the individual changes. In short, you mean specify S0IDLE for
certain sysctls to enable the support.

For example, sysctl hw.acpi.suspend_state=S0IDLE, will make acpiconf -s3 use
suspend to idle instead of the default (NONE or S3).

On top of this series will be support for s0ix (emulated s3), and then after
that, hopefully some sort of runtime power management. Emulated S3 support is
"done" and being debugged is here:
https://github.com/bwidawsk/freebsd/tree/s0ix

Test Plan

Set suspend to use suspend to idle, use power button to wake machine.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 20374
Build 19815: arc lint + arc unit

Event Timeline

Is this one ready to be reviewed?

I think so. I think there are definitely some robustifications needed, but generally it'd be good to know if I need any major overhauls. Also, at this point in the series, it's entirely opt-in, and any regressions should be fixable.

imp added inline comments.
sys/dev/acpica/acpi.c
2927

Would it be appropriate to have a printf here? I'm on the fence about this.

2994

Same comment as above.

4006

I see s2idle and other things like that in the rest of the code. Do we need that here too?

sys/dev/acpica/acpivar.h
73

would it make sense to make this a named struct instead of repeating?

sys/dev/acpica/acpi.c
3171

Presumably this may fail on !EARLY_AP_STARTUP archs (e.g. arm64)

For EARLY_AP_STARTUP the case with and without if (smp_started) should behave equivalently I believe; @jhb?

sys/dev/acpica/acpi.c
179–180

Sometimes we use enum sleep_type stype and sometimes enum sleep_type type - should be consistent

3065

A rebased version of this patch works somewhat.

Running:

sysctl hw.acpi.suspend_state=S0IDLE
acpiconf -s3

results in an apparent suspend (but the power light remains on, does not enter the flashing suspended indication state).

There are some problems with snd_hda

[418.726124] hdac0: Command 0x0103b080 timeout on address 0
[418.832034] hdac0: Command 0x0103b080 timeout on address 0
[418.937959] hdac0: Command 0x0103b080 timeout on address 0
[419.043886] hdac0: Command 0x0193b080 timeout on address 0
...
[420.661122] hdacc0: Unexpected unsolicited response with tag 63: ffffffff
[420.661163] hdacc0: Unexpected unsolicited response with tag 63: ffffffff
[420.661203] hdacc0: Unexpected unsolicited response with tag 63: ffffffff
[420.661242] hdacc0: Unexpected unsolicited response with tag 63: ffffffff
[420.661282] hdacc0: Unexpected unsolicited response with tag 63: ffffffff
...

Messages observed from shutdown:

[747.432111] uhub0: at usbus1, port 1, addr 1 (disconnected)
[747.432158] ugen1.2: <Compx 2.4G Receiver> at usbus1 (disconnected)
[747.432183] ukbd0: at uhub0, port 3, addr 1 (disconnected)
[747.440948] ukbd0: detached
[747.440971] ums0: at uhub0, port 3, addr 1 (disconnected)
[747.443940] ums0: detached
[747.447241] ugen1.3: <Generic Laptop Camera> at usbus1 (disconnected)
[747.450181] ugen1.4: <Goodix Technology Co., Ltd. Goodix USB2.0 MISC> at usbus1 (disconnected)
[747.453230] ugen1.5: <vendor 0x8087 product 0x0032> at usbus1 (disconnected)
[747.456206] uhub0: detached
[747.525212] uhub1: at usbus0, port 1, addr 1 (disconnected)
[747.525229] uhub1: detached
[748.006140] vgapci0: child drmn0 requested pci_set_powerstate
[748.017144] pci0: failed to set ACPI power state D3 on \134_SB_.PC00.GFX0: AE_BAD_PARAMETER

And from resume:

[750.183958] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=0 io_irq=-1 error=0
[750.184011] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=0 io_irq=1 error=0
[750.184063] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=4 io_irq=0 error=0
[750.184136] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=0 io_irq=8 error=0
[750.184187] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=0 io_irq=9 error=0
[750.184343] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=4 io_irq=16 error=0
[750.184408] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=6 io_irq=27 error=0
[750.184485] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=2 io_irq=30 error=0
[750.184546] ioapic_program_intpin: iommu_map_ioapic_intr io_apic_id=2 io_cpu=0 io_irq=40 error=0
[750.226331] vgapci0: child drmn0 requested pci_set_powerstate
[750.226904] vgapci0: child drmn0 requested pci_enable_io
[750.226919] vgapci0: child drmn0 requested pci_enable_io
[751.179892] uhub0 on usbus0
[751.179927] uhub0: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
[751.180514] uhub1 on usbus1
[751.180540] uhub1: <Intel XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
[751.604251] uhub0: 5 ports with 5 removable, self powered
[752.060242] uhub1: 16 ports with 16 removable, self powered
[752.548076] ugen1.2: <Compx 2.4G Receiver> at usbus1
[752.549151] ukbd0 on uhub1
[752.549179] ukbd0: <Compx 2.4G Receiver, class 0/0, rev 1.10/6.91, addr 1> on usbus1
[752.550675] kbd2 at ukbd0
[752.553224] ums0 on uhub1
[752.553246] ums0: <Compx 2.4G Receiver, class 0/0, rev 1.10/6.91, addr 1> on usbus1
[752.555708] ums0: 5 buttons and [XYZT] coordinates ID=1
[753.006850] ugen1.3: <Generic Laptop Camera> at usbus1
[753.833426] ugen1.4: <Goodix Technology Co., Ltd. Goodix USB2.0 MISC> at usbus1
[754.279692] ugen1.5: <vendor 0x8087 product 0x0032> at usbus1

For anyone looking into this the ACPI reference table might help:

https://uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf

While figuring out if I have a machine with s2idle on linux I found this Intel tool:
https://github.com/intel/S0ixSelftestTool

Note that this s2idle patch is distinct from but a prerequisite for s0ix. This change does not have hardware dependencies (beyond existing functionality) and merely idles the CPUs during "suspend."

Thanks Ed, I think that is a useful clarification.

It looks like the existing s0iX repo has been deleted, do you have a copy somewhere or is it lost to time?

In D17675#1066569, @thj wrote:

It looks like the existing s0iX repo has been deleted, do you have a copy somewhere or is it lost to time?

The repo is sadly gone but a snapshot of the work is in D17676