Bug 196861 - S0ix enablement - Asus E200HA (Atom x5-Z8300, Cherrytrail)
Summary: S0ix enablement - Asus E200HA (Atom x5-Z8300, Cherrytrail)
Status: RESOLVED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-09-07 22:14 UTC by Johannes Stezenbach
Modified: 2018-12-27 11:29 UTC (History)
8 users (show)

See Also:
Kernel Version: v4.13
Tree: Mainline
Regression: No


Attachments

Description Johannes Stezenbach 2017-09-07 22:14:28 UTC
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
Comment 1 Dainius Masiliūnas 2017-09-07 22:45:10 UTC
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.
Comment 2 Zhang Rui 2017-09-12 01:33:00 UTC
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.
Comment 3 Dainius Masiliūnas 2017-09-12 08:29:12 UTC
OK, I split it off to https://bugzilla.kernel.org/show_bug.cgi?id=196915.
Comment 5 Chen Yu 2018-03-12 00:09:03 UTC
Thanks for the info, RussianNeuroMancer.

Dainius, could you please test on latest 4.16-rc4
Comment 6 youling257 2018-03-12 02:19:17 UTC
(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:/ #
Comment 8 Hans de Goede 2018-09-03 20:15:18 UTC
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
Comment 9 Johannes Stezenbach 2018-09-04 09:23:18 UTC
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!
Comment 10 Hans de Goede 2018-09-04 10:03:57 UTC
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.
Comment 11 Chen Yu 2018-12-27 06:35:51 UTC
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?
Comment 12 Hans de Goede 2018-12-27 11:29:04 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.