Created attachment 273951 [details]
dmesg after suspending (kernel compiled with acpi debug features enabled)
With kernel releases candidates around v4.14-rc7 there was a brief period the kernel allowed my Asus X205TA to reach S0I3
suspend state (with power led off) as it does under windows, this state is very power efficient. In later releases of v4.14 I
needed to revert a commit by Rafael J. Wysocki <email@example.com> (specifically the runtime.c hunk):
To achieve the same results.
Since v4.15 I am not able to revert this hunk anymore (because then i2c_designware_core will break on hibernation). The laptop
will now only suspend with the led light on (and /sys/kernel/debug/pmc_atom/sleep_state shows the laptop resides only in S0 state
instead of S0I3).
From the commits that followed later on that seem to block the X205TA from reaching S0I3 state I gather (I am not a coder) that
the 4.14 release candidates that worked for me put devices to S0I3 state unconditionally (which I assume breaks stuff on some
other devices). I also gather that now that certain runtime conditions need to be met to be able to enter S0I3 sleep state, the
X205TA somehow does not meet those conditions.
I have been unable to find out which runtime conditions don't allow the laptop to enter S0I3 state. I am not really sure which information I should provide here, I attached a dmesg output after suspend (with acpi debug features enabled in the kernel). If any more information is necessary, please let me know and I'll supply them.
I found some more bug threads pertaining this issue.
As Zhang Rui stated that S0ix support has platform specific dependencies. I'll provide some more info about the device (as others have done for their devices in the above listed bugthreads.)
Created attachment 274041 [details]
Created attachment 274043 [details]
Created attachment 274045 [details]
Created attachment 274047 [details]
(In reply to harryharryharry from comment #0)
> Created attachment 273951 [details]
> dmesg after suspending (kernel compiled with acpi debug features enabled)
> With kernel releases candidates around v4.14-rc7 there was a brief period
> the kernel allowed my Asus X205TA to reach S0I3
> suspend state (with power led off) as it does under windows, this state is
> very power efficient. In later releases of v4.14 I
> needed to revert a commit by Rafael J. Wysocki <firstname.lastname@example.org>
> (specifically the runtime.c hunk):
> To achieve the same results.
May I know how did you figure out the first bad commit? Just curious on how to debug such kind of s0ix residency issues..
Sorry not much I can help you with as I'm struggling with debugging this issue myself. Finding the commit was a combination of perseverance and dumb luck :) I'm testing out each new rc so I had it narrowed down to the commits in one rc already. After that it was lots of trying reverse patching the commits I thought could be the cause...
I see you changed the status to NEEDINFO. Which info is needed and (how) can I supply it ?
Please attach the output of "cat /proc/cpuinfo"
Created attachment 275737 [details]
cpuinfo - asus x205ta
I think I found something that might help debug this issue:
when I do: echo 0x00800000 > /sys/module/acpi/parameters/debug_layer
Dmesg shows a device called SDHA is constantly being switched from D3hot to D0 and back.
I have a hacky patched kernel that basically reverts a bunch of commits to v4.14-rc7 state - which still allows s0i3 state - and this patched kernel does not exhibit this behaviour (the SDHA device goes to and stays in D3hot when suspending.)
I'll add the 2 dmesgs from patched and unpatched kernel below.
Created attachment 277671 [details]
dmesg debug 4.18.0-rc7 patched kernel
Created attachment 277673 [details]
dmesg debug 4.18.0-rc7 unpatched kernel
my tablet is BYTCR z3735f，
S0IR Residency: 1568us
S0I1 Residency: 1792us
S0I2 Residency: 30144us
S0I3 Residency: 3903136us
S0 Residency: 1043594112us
seem because https://github.com/torvalds/linux/commit/12864ff8545f6b8144fdf1bb89b5663357f29ec4
but resume failed，auto reboot，
mmc1: error -110 doing runtime resume
bdi-block not register
this is other one problem mmc not support s0i3 on BYTCR.
Excellent find, thanks for sharing! I just tested a 4.18.0-rc7 kernel with only that commit applied, and it enables s0i3 suspend for me again. Suspending and even hibernating (which previously resulted in keyboard/touchpad issues) also work reasonably fine now! (sound doesn't work after hibernation, powerbutton doesn't work after suspending. But I think I better make separate bug reports for those.)
I tested Linux 4.18rc8 which include mentioned commit and find that at least on HP Stream 7 Tablet there is no mentioned mmc. I doesn't get S0i3 residency - S0i1 at most. However, instead of mmc issue on this tablet after wakeup axp288 driver stop reporting battery level and stop react on power button.
(In reply to RussianNeuroMancer from comment #16)
> I tested Linux 4.18rc8 which include mentioned commit and find that at least
> on HP Stream 7 Tablet there is no mentioned mmc. I doesn't get S0i3
> residency - S0i1 at most. However, instead of mmc issue on this tablet after
> wakeup axp288 driver stop reporting battery level and stop react on power
the different of /sys/kernel/debug/pmc_atom/dev_state is only DMA can entry D3 ,
diff before and now dev_state .
@@ -1,4 +1,4 @@
-Dev: 0 - LPSS1_F0_DMA State: Enabled [D0]
+Dev: 0 - LPSS1_F0_DMA State: Enabled [D3]
Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0]
Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3]
Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0]
@@ -22,7 +22,7 @@
Dev: 21 - PCIE_PORT1 State: Enabled [D0]
Dev: 22 - PCIE_PORT2 State: Enabled [D0]
Dev: 23 - PCIE_PORT3 State: Enabled [D0]
-Dev: 24 - LPSS2_F0_DMA State: Enabled [D0]
+Dev: 24 - LPSS2_F0_DMA State: Enabled [D3]
Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3]
Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3]
Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3]
Same on HP Stream 7, both of LPSS1_F0_DMA and LPSS2_F0_DMA in Enabled state now. Also:
Dev: 8 - SCC_EMMC State: Disabled [D0]
Dev: 9 - SCC_SDIO State: Enabled [D3]
Dev: 10 - SCC_SDCARD State: Enabled [D0]
Dev: 11 - SCC_MIPI State: Enabled [D3]
It is same on your tablet?
(In reply to RussianNeuroMancer from comment #18)
> Same on HP Stream 7, both of LPSS1_F0_DMA and LPSS2_F0_DMA in Enabled state
> now. Also:
> Dev: 8 - SCC_EMMC State: Disabled [D0]
> Dev: 9 - SCC_SDIO State: Enabled [D3]
> Dev: 10 - SCC_SDCARD State: Enabled [D0]
> Dev: 11 - SCC_MIPI State: Enabled [D3]
> It is same on your tablet?
scc_emmc、sdio、sdcard all same，bios may be same .
bios has scc emmc 4.5 enable，if disable scc sdio and sdcard，then boot userspace，only has mmc0 for emmc 4.5，no 8723bs and sdcard，mmc0 also will resume failed.
bios has scc emmc 4.5 enable，but dev_state scc_emmc disabled.
if you change lpss&scc to pci mode，can you boot ?
4.14.61 kernel just need drivers/base/power/runtime.c
- else if (__dev_pm_qos_read_value(dev) < 0)
+ else if (__dev_pm_qos_read_value(dev) == 0)
can make F0_DMA entry d3，sleep_state ca reach s0i3，but has more resume problem for my tablet.
as he said "Some drivers may not support it"，https://github.com/torvalds/linux/commit/d5919dcc349d2a16d805ef8096d36e4f519e42ae
4.14 rc8 d5919dcc349d2a16d805ef8096d36e4f519e42ae is correct，
4.14 rc7 0cc2b4e only because "== 0" make reach s0i3，but has some resume problem.
so has 4.15 rc1 0759e80b84e34a84e7e46e2b1adb528c83d84a47，but this "== 0" not make reach s0i3，until 4.18rc8 kernel，it can rework for s0i3，
still has some resume problem about pm_qos value is 0 .
> if you change lpss&scc to pci mode，can you boot ?
This settings is not available in HP Stream 7 Tablet BIOS.
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:
2) A set of fixes to make sure the PMC clocks are disabled during boot
3) Make sure the 2nd pwm controller on Cherry Trail gets a driver
attached and thus gets properly suspended:
4) A dummy driver for the Cherry Trail ISP processor (builtin camera sensor interface), so that the ISP properly gets suspended / put in D3.
3 and 4 only apply to Cherry Trail devices (such as the Asus E200HA this bug was originally opened for).
harryharryharry, 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.
Hi Hans, thanks for your work!
Although my device already suspends to s0i3 again since 4.18.0-rc7 (see comment #15), if needed I'll gladly test your patches. Silly question: what's the easiest way to apply the commits on github you linked to, to say, a 4.18.5 tarball ? (I can't seem to find a 'raw patch' type download on github)
Off topic: I've recently tested this patch:
[PATCH v2] brcmfmac: Add support for getting nvram contents from EFI variables
which works beautifully on 4.16.x, but I can't apply it anymore to subsequent kernels. I this patch being merged to the mainline kernel soon? (or is there some way to apply it to newer kernels?)
(In reply to harryharryharry from comment #23)
> Hi Hans, thanks for your work!
> Although my device already suspends to s0i3 again since 4.18.0-rc7 (see
> comment #15)
Right, but with regressions to the power-button after suspend-resume, my patches (first one specifically) should fix that.
> if needed I'll gladly test your patches.
It would be good to get confirmation that my patches fix the regressions you are seeing with 4.18.0-rc7, while still allowing s0i3.
> Silly question:
> what's the easiest way to apply the commits on github you linked to, to say,
> a 4.18.5 tarball ? (I can't seem to find a 'raw patch' type download on
Add .patch at the end of URLs to get files which you can git am, e.g. :
> Off topic: I've recently tested this patch:
> [PATCH v2] brcmfmac: Add support for getting nvram contents from EFI
> which works beautifully on 4.16.x, but I can't apply it anymore to
> subsequent kernels. I this patch being merged to the mainline kernel soon?
> (or is there some way to apply it to newer kernels?)
I need to respin that patch, splitting out the somewhat controversial world domain mangling bits into a separate patch in the mean time you can find a rebased version here:
And specifically this commit (for 4.18) :
S0i3 works now on HP Stream 7 Tablet:
~# cat /sys/kernel/debug/pmc_atom/sleep_state
S0IR Residency: 171136us
S0I1 Residency: 1184us
S0I2 Residency: 15904us
S0I3 Residency: 599030240us
S0 Residency: 144164480us
Thanks you! :)
Thanks for the neat url+.patch trick :)
All s0ix modes also work for me with the patches and the power button still works after suspend and/or hibernate. (I had to change the 'dummy driver' patch a little because the Makefile hunk wouldn't apply properly, due to the CONFIG_I2C_MULTI_INSTANTIATE line missing in the original Makefile).
Now the only thing not working after hibernate is audio.
ps: Also, thank you for the tip about the brcmfmac patch, that patch does the trick again on 4.18.
Hmmm, I just built 4.19-rc3 and the s0i3 state is not available again. I've looked at the diff between rc2 (with which s0i3 is working) and rc3, and it appears to be the following commit:
ACPI / LPSS: Force LPSS quirks on boot (Zhang Rui)
If I compile rc3 with this commit reverted, s0i3 is enabled again.
(In reply to harryharryharry from comment #27)
> Hmmm, I just built 4.19-rc3 and the s0i3 state is not available again. I've
> looked at the diff between rc2 (with which s0i3 is working) and rc3, and it
> appears to be the following commit:
> ACPI / LPSS: Force LPSS quirks on boot (Zhang Rui)
> If I compile rc3 with this commit reverted, s0i3 is enabled again.
Yes, this is caused by the fix for bug 200989 and is being discussed there.
Instead of reverting that commit, can you try adding these 2 patches instead? :
I expect those will fix this again for you, these are queued up for merging into 4.20.
If those 2 do not fix things also try adding:
That is likely how we will end up fixing this, so getting confirmed that this fixes it for you would be good.
Thanks for the fast reply!
I 'reapplied' the commit from comment #27 and applied the first 2 commits you linked to, and the s0i3 state could not yet be reached after recompiling.
With the third patch also applied, the s0i3 state can be reached again.
(In reply to harryharryharry from comment #29)
> Thanks for the fast reply!
Thank you for the quick testing.
> I 'reapplied' the commit from comment #27 and applied the first 2 commits
> you linked to, and the s0i3 state could not yet be reached after recompiling.
> With the third patch also applied, the s0i3 state can be reached again.
OK, that means that the X205TA has a PMIC where the I2C to the PMIC is shared between the OS (the Linux kernel) and the PUNIT inside the SoC.
I've several of those devices myself so although it is not yet entirely sure how we will resolve this, I'm sure that we will fix this somehow. ATM it seems likely this will be done through the 3th patch which you added.
Thanks for the explanation and good luck with the puzzle!
Quick status update, it looks like we will indeed go with the 3th patch you added as fix for this.
I'm not see it improve battery life,suspend one hour,usage 8%,suspend 4 hours,usage 30%.
battery 5000mah，every hour discharge 400mah，Discharge at 400 Ma per second.
S0IR Residency: 9664us
S0I1 Residency: 29216us
S0I2 Residency: 5898983424us
S0I3 Residency: 11603320512us
S0 Residency: 6721288608us