S0ix does not work on Intel Atom (Cherrytrail at least). On Asus E200HA (Atom x5-Z8300, Cherrytrail) I was able to enter S0ix with some hacks, so apparently not much is missing but one difficulty is that the exact requirements for the SoC to enter S0ix are not publicly documented. Hardware will enter S0ix when the conditions are met and software (intel_idle) executes MWAIT(C7) on all cores. Intel_ACPI_Low_Power_S0_Idle.pdf describes the Get Device Constraints _DSM on PNP0D80 that BIOS uses to list the devices which need to be in D3 for S0ix. On E200HA, one of them is I2C7. However, the PMIC is attached to I2C7 and other device drivers may call ACPI methods on suspend which in turn may cause PMIC communication via ACPI OpRegions. I.e. we must make sure I2C7 is operational until very late during suspend (and very early during resume). Currently i2c-designware just disables pm for I2C7, which makes it not crash but prevents S0ix. At least this is the theory, in practise I could enter S0ix with I2C7 enabled, however designware DMA must be disabled. dw DMA is connected to dw I2C, but the I2C driver does not currently support DMA. Nevertheless code in acpi_lpss.c has some special handling that keeps DMA hardware enabled until all potential users (I2C, SPI, UART) are suspended. I.e. when I2C7 is not suspended, DMA will also not be suspended and this blocks S0ix. As a test hack I just directly poked the PMC FUNC_DIS register to disable DMA manually. Apparently what we need is a way to suspend dw I2C later than .suspend_late and make this work with the interaction of acpi and lpss power domains. On E200HA, one more issue that prevents S0ix is that the SATA hardware is enabled by BIOS, but SATA is not supported (isn't used and doesn't show up in lspci). So I just disabled it in FUNC_DIS, too. Another issue I found in v4.13 is that commit d31fd43c0f9a4 "clk: x86: Do not gate clocks enabled by the firmware" broke my S0ix hacks. This commit was needed to prevent a hang on boot on Asus Z550M (Baytrail). No idea yet what to do about it. DSDT and other info can be found in bug #193891
Yes, right now it doesn't seem to work properly on HP x2 210 either, at least according to the debugfs statistics. The tablet looks very convincingly as if it was suspended, but the metrics reported show no residency in any of the S0ix states. Unfortunately it also has no LED that would indicate its suspend status (there is only a "battery charging" LED, and I suppose also the caps lock LED on the detachable keyboard, but that's it). I tested it with the topic/dollar-cove-ti-4.13-v4 kernel, without any of the commits from the other branches. The tablet's DSDT is in https://bugzilla.kernel.org/attachment.cgi?id=256669 . Would be nice to know if there is anything I could do to test this further.
S0ix support have platform specific dependency, thus I think it is a different problem on HP. Dainius, please file a new bug report instead, with detailed information and full acpidump and lspci output.
OK, I split it off to https://bugzilla.kernel.org/show_bug.cgi?id=196915.
https://www.dpin.de/nf/finally-s0i3-is-there-thinkpad-tablet-10-sleeps-deeply-with-linux-kernel-4-15rc/
Thanks for the info, RussianNeuroMancer. Dainius, could you please test on latest 4.16-rc4
(In reply to Chen Yu from comment #5) > Thanks for the info, RussianNeuroMancer. > > Dainius, could you please test on latest 4.16-rc4 z3735f，bios support s0i3. <6>[ 274.130133] PM: suspend entry (s2idle) <6>[ 274.130153] PM: Syncing filesystems ... done. <6>[ 274.183892] Freezing user space processes ... (elapsed 0.004 seconds) done. <6>[ 274.188912] OOM killer disabled. <6>[ 274.188917] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. <4>[ 274.190813] Suspending console(s) (use no_console_suspend to debug) <6>[ 274.223440] rt5640 i2c-10EC5640:00: irq status 0x100 <6>[ 274.239608] sst-mfld-platform sst-mfld-platform: Enter: enable=0 port_name=media-cpu-dai <6>[ 274.240333] sst-mfld-platform sst-mfld-platform: Enter: enable=0 port_name=ssp0-port <4>[ 274.243273] RTL8723BS: suspend start <6>[ 274.244889] serial 00:02: disabled <7>[ 274.244939] rtc_cmos 00:00: suspend, ctrl 02 <5>[ 274.247908] sd 0:0:0:0: [sda] Synchronizing SCSI cache <6>[ 274.281033] intel_sst_acpi 80860F28:00: Free for str 1 pipe 0x90 <6>[ 274.344747] rt5640 i2c-10EC5640:00: irq status 0xffffffff <6>[ 274.345015] rt5640 i2c-10EC5640:00: detect status 0x0 <4>[ 274.675099] RTL8723BS: rtw_cmd_thread(wlan0) stop_req:1, break <4>[ 274.677248] RTL8723BS: rtw_dev_unload: driver not in IPS <4>[ 274.688408] RTL8723BS: rtw suspend success in 445 ms <4>[ 282.591513] RTL8723BS: resume start <6>[ 282.600387] rtl8723bs: acquire FW from file:rtlwifi/rtl8723bs_nic.bin <6>[ 282.682265] intel_sst_acpi 80860F28:00: Alloc for str 1 pipe 0x90 <3>[ 282.777966] rtc_cmos 00:00: Could not get RTC status <7>[ 282.777972] rtc_cmos 00:00: resume, ctrl 22 <4>[ 284.140685] RTL8723BS: rtw_resume_common:0 in 1549 ms <6>[ 284.140895] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=media-cpu-dai <6>[ 284.141054] sst-mfld-platform sst-mfld-platform: Enter: enable=1 port_name=ssp0-port <6>[ 284.141913] OOM killer enabled. <6>[ 284.141919] Restarting tasks ... done. <6>[ 284.143787] PM: suspend exit u0_a27@x86_64:/ $ su root@x86_64:/ # root@x86_64:/ # cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 0us S0I1 Residency: 0us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 31284461696us root@x86_64:/ # uname -a Linux localhost 4.16.0-rc4-android-x86_64+ #1 SMP PREEMPT Thu Mar 8 21:58:10 CST 2018 x86_64 GNU/Linux root@x86_64:/ # uname -a Linux localhost 4.16.0-rc4-android-x86_64+ #1 SMP PREEMPT Thu Mar 8 21:58:10 CST 2018 x86_64 GNU/Linux root@x86_64:/ # cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 0us S0I1 Residency: 0us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 31416759552us root@x86_64:/ # cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 0us S0I1 Residency: 0us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 31470280640us root@x86_64:/ #
https://bugzilla.kernel.org/show_bug.cgi?id=198631#c14
Hi All, I've been working on fixing S0ix support for most Bay and Cherry Trail devices recently. For me it works on all devices I've tested using 4.18.x + the following patches: 1) A fix for the i2c controller connected to the PMIC no longer working after suspend/resume: https://github.com/jwrdegoede/linux-sunxi/commit/49ae76ac49f104fd06a96b7e41c5c02991a33684 2) A set of fixes to make sure the PMC clocks are disabled during boot https://github.com/jwrdegoede/linux-sunxi/commit/21727f53891a3b7162474680a3ad7725a1b19308 https://github.com/jwrdegoede/linux-sunxi/commit/1c0f485edb8bdc0def5ba4aebe394bf11e207d16 https://github.com/jwrdegoede/linux-sunxi/commit/a2290d4ab214753162f3d89d4e72921ca22f46ad 3) Make sure the 2nd pwm controller on Cherry Trail gets a driver attached and thus gets properly suspended: https://github.com/jwrdegoede/linux-sunxi/commit/2870b0d7537d7c2d1f2724e4171ca47fe1aaa7b9 4) A dummy driver for the Cherry Trail ISP processor (builtin camera sensor interface), so that the ISP properly gets suspended / put in D3. https://github.com/jwrdegoede/linux-sunxi/commit/548d9dba657947708a887ba3b41b5a9b74343a04 3 and 4 only apply to Cherry Trail devices (such as the Asus E200HA this bug was originally opened for). Johannes, as discussed by email please try a 4.18.x kernel with the above patches added and let me know here in bugzilla if that makes the laptop properly enter/use S0ix modes. Other people following this bug, also please try a 4.18.x kernel with the above patches, if you still do not get S0ix mode an a Bay or Cherry Trail based device , please open a *new* bug for that and let me know about it. Regards, Hans
I briefly tested 4.18.5 with your patches on E200HA (minor conflict in Makefile/Kconfig wrt I2C_MULTI_INSTANTIATE for the last patch). And S0i3 works! (Without any other fiddling like the SATA bit hack.) # echo mem >/sys/power/state <wake up by keyboard> # cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 96us S0I1 Residency: 17248us S0I2 Residency: 53600us S0I3 Residency: 24856128us S0 Residency: 555691904us A big Thank You!
Thank you for testing, so that means that this bug can be closed once all patches are in next. So far the patch from 1) has been accepted and patch 3) has been Acked. I need to do some minor fixes to 2) and 4) and then send out a new version.
Hi Hans, thanks for your help on this issue, since patch 1 and 3 were merged at commit 9d9a152ebaa86a9dede4624919566483c955d0a7 and commit 1688c8717118f37191d824862a006c8373d261de May I know if 2 and 4 would also be pushed to upstream?
(In reply to Chen Yu from comment #11) > Hi Hans, > thanks for your help on this issue, since > patch 1 and 3 were merged at > > commit 9d9a152ebaa86a9dede4624919566483c955d0a7 > and > commit 1688c8717118f37191d824862a006c8373d261de > > May I know if 2 and 4 would also be pushed to upstream? Yes, the series from 2) above are upstream as commits: commit b1e3454d39f992e5409cd19f97782185950df6e7 commit ac8bd9e13be22a3d24bfc80972d4688e3e50e457 commit 648e921888ad96ea3dc922739e96716ad3225d7f And 4) is upstream as: commit 49ad712afa88c502831d37f7089d98eac441fb80 So this can be closed.