Bug 198631 - No S0ix residency - Asus X205TA
Summary: No S0ix residency - Asus X205TA
Status: NEEDINFO
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-31 21:22 UTC by harryharryharry
Modified: 2018-09-24 13:20 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.15
Tree: Mainline
Regression: No


Attachments
dmesg after suspending (kernel compiled with acpi debug features enabled) (222.62 KB, text/plain)
2018-01-31 21:22 UTC, harryharryharry
Details
acpidump (421.79 KB, text/plain)
2018-02-07 11:23 UTC, harryharryharry
Details
dsdt.dsl (610.28 KB, text/x-csrc)
2018-02-07 11:24 UTC, harryharryharry
Details
lspci -v (2.33 KB, text/plain)
2018-02-07 11:24 UTC, harryharryharry
Details
pcm_atom_states (3.35 KB, text/plain)
2018-02-07 11:25 UTC, harryharryharry
Details
cpuinfo - asus x205ta (3.92 KB, text/plain)
2018-05-02 21:26 UTC, harryharryharry
Details
dmesg debug 4.18.0-rc7 patched kernel (65.25 KB, text/plain)
2018-08-02 20:13 UTC, harryharryharry
Details
dmesg debug 4.18.0-rc7 unpatched kernel (70.12 KB, text/plain)
2018-08-02 20:14 UTC, harryharryharry
Details

Description harryharryharry 2018-01-31 21:22:56 UTC
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 <rafael.j.wysocki@intel.com> (specifically the runtime.c hunk):
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20180129&id=d5919dcc349d2a16d805ef8096d36e4f519e42ae
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.
Comment 1 harryharryharry 2018-02-07 11:22:29 UTC
I found some more bug threads pertaining this issue. 
https://bugzilla.kernel.org/show_bug.cgi?id=196861
https://bugzilla.kernel.org/show_bug.cgi?id=196915

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.)
Comment 2 harryharryharry 2018-02-07 11:23:10 UTC
Created attachment 274041 [details]
acpidump
Comment 3 harryharryharry 2018-02-07 11:24:25 UTC
Created attachment 274043 [details]
dsdt.dsl
Comment 4 harryharryharry 2018-02-07 11:24:46 UTC
Created attachment 274045 [details]
lspci -v
Comment 5 harryharryharry 2018-02-07 11:25:36 UTC
Created attachment 274047 [details]
pcm_atom_states

cat /sys/kernel/debug/pmc_atom/{sleep,dev,pss}_state
Comment 6 Chen Yu 2018-03-12 01:55:32 UTC
(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 <rafael.j.wysocki@intel.com>
> (specifically the runtime.c hunk):
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/
> ?h=next-20180129&id=d5919dcc349d2a16d805ef8096d36e4f519e42ae
> 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..
Comment 7 harryharryharry 2018-03-12 09:57:56 UTC
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...
Comment 8 harryharryharry 2018-04-03 15:29:19 UTC
@Chen Yu
I see you changed the status to NEEDINFO. Which info is needed and (how) can I supply it ?
Comment 9 Zhang Rui 2018-05-02 06:14:34 UTC
Please attach the output of "cat /proc/cpuinfo"
Comment 10 harryharryharry 2018-05-02 21:26:23 UTC
Created attachment 275737 [details]
cpuinfo - asus x205ta
Comment 11 harryharryharry 2018-08-02 20:12:23 UTC
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.
Comment 12 harryharryharry 2018-08-02 20:13:31 UTC
Created attachment 277671 [details]
dmesg debug 4.18.0-rc7 patched kernel
Comment 13 harryharryharry 2018-08-02 20:14:08 UTC
Created attachment 277673 [details]
dmesg debug 4.18.0-rc7 unpatched kernel
Comment 14 youling257 2018-08-03 08:32:30 UTC
my tablet is BYTCR z3735f,

unbelievable ! 

cat /sys/kernel/debug/pmc_atom/sleep_state
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 

[cut here]
bdi-block not register
call trace:
_set_page_dirty 

this is other one problem mmc not support s0i3 on BYTCR.
Comment 15 harryharryharry 2018-08-03 12:00:01 UTC
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.)
Comment 16 RussianNeuroMancer 2018-08-06 12:53:47 UTC
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.
Comment 17 youling257 2018-08-06 13:00:03 UTC
(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
> button.

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]
Comment 18 RussianNeuroMancer 2018-08-06 13:14:12 UTC
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?
Comment 19 youling257 2018-08-06 13:25:42 UTC
(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 ?
Comment 20 youling257 2018-08-07 14:46:08 UTC
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 .
Comment 21 RussianNeuroMancer 2018-08-08 17:08:39 UTC
> if you change lpss&scc to pci mode,can you boot ?

This settings is not available in HP Stream 7 Tablet BIOS.
Comment 22 Hans de Goede 2018-09-03 20:25:02 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).

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.

Regards,

Hans
Comment 23 harryharryharry 2018-09-04 00:15:41 UTC
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
https://www.spinics.net/lists/linux-wireless/msg171359.html
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?)
Comment 24 Hans de Goede 2018-09-04 07:26:24 UTC
Hi,

(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
> github) 

Add .patch at the end of URLs to get files which you can git am, e.g. :

https://github.com/jwrdegoede/linux-sunxi/commit/49ae76ac49f104fd06a96b7e41c5c02991a33684.patch

> Off topic: I've recently tested this patch:
> [PATCH v2] brcmfmac: Add support for getting nvram contents from EFI
> variables
> https://www.spinics.net/lists/linux-wireless/msg171359.html
> 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:

https://github.com/jwrdegoede/linux-sunxi/tree/v4.18-footrail

And specifically this commit (for 4.18) :

https://github.com/jwrdegoede/linux-sunxi/commit/9cfa9a18ca200b7827da09460fb161010bb2a4c74.patch

Regards,

Hans
Comment 25 RussianNeuroMancer 2018-09-04 09:55:12 UTC
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! :)
Comment 26 harryharryharry 2018-09-04 20:36:40 UTC
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.
Gr Harry

ps: Also, thank you for the tip about the brcmfmac patch, that patch does the trick again on 4.18.
Comment 27 harryharryharry 2018-09-10 17:29:05 UTC
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)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.19-rc3&id=f11fc4bc669b8622510c1039499f5a9d24248fec

If I compile rc3 with this commit reverted, s0i3 is enabled again.
Comment 28 Hans de Goede 2018-09-10 18:17:37 UTC
(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)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?h=v4.19-rc3&id=f11fc4bc669b8622510c1039499f5a9d24248fec
> 
> 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? :

https://github.com/jwrdegoede/linux-sunxi/commit/06c152e724237bad7f31df7da554ae1ab27454a9.patch
https://github.com/jwrdegoede/linux-sunxi/commit/fec7df233c9e9668d95c6d5756f7ceb5be0239fe.patch

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:

https://github.com/jwrdegoede/linux-sunxi/commit/29b8592d679bd1a086dd88b8273c40c8ace37ca6.patch

That is likely how we will end up fixing this, so getting confirmed that this fixes it for you would be good.
Comment 29 harryharryharry 2018-09-10 18:43:27 UTC
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.
Comment 30 Hans de Goede 2018-09-10 19:36:21 UTC
Hi,

(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.

Regards,

Hans
Comment 31 harryharryharry 2018-09-11 09:05:08 UTC
Thanks for the explanation and good luck with the puzzle!
Comment 32 Hans de Goede 2018-09-11 09:24:26 UTC
Quick status update, it looks like we will indeed go with the 3th patch you added as fix for this.
Comment 33 youling257 2018-09-24 13:20:35 UTC
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.

cat /sys/kernel/debug/pmc_atom/sleep_state
S0IR Residency: 9664us
S0I1 Residency: 29216us
S0I2 Residency: 5898983424us
S0I3 Residency: 11603320512us
S0   Residency: 6721288608us

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