Bug 196915 - S0ix: no residency in S0ix - HP x2 210
Summary: S0ix: no residency in S0ix - HP x2 210
Status: NEEDINFO
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-12 08:28 UTC by Dainius Masiliūnas
Modified: 2021-01-25 08:44 UTC (History)
8 users (show)

See Also:
Kernel Version: 4.13
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (106.49 KB, text/plain)
2017-09-12 08:28 UTC, Dainius Masiliūnas
Details
/sys/kernel/debug/pmc_atom/{sleep,dev,pss}_state (3.39 KB, text/plain)
2017-09-12 08:30 UTC, Dainius Masiliūnas
Details
lspci -v (5.04 KB, text/plain)
2017-09-12 08:34 UTC, Dainius Masiliūnas
Details
acpidump (846.33 KB, text/plain)
2017-09-12 08:36 UTC, Dainius Masiliūnas
Details
dsdt.dsl (1.21 MB, text/plain)
2017-09-12 08:37 UTC, Dainius Masiliūnas
Details

Description Dainius Masiliūnas 2017-09-12 08:28:43 UTC
Created attachment 258321 [details]
dmesg

On HP x2 210 tablet with the kernel https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=topic/dollar-cove-ti-4.13-v4 the suspend to idle functionality appears to work, yet on resume the kernel debug entry /sys/kernel/debug/pmc_atom/sleep_state shows no residency in any of the S0ix states, only S0:
S0IR Residency:	0us
S0I1 Residency:	0us
S0I2 Residency:	0us
S0I3 Residency:	0us
S0   Residency:	1205902784us

Kernel log, debug output, acpidump, dsdt and lspci are attached.
Comment 1 Dainius Masiliūnas 2017-09-12 08:30:28 UTC
Created attachment 258323 [details]
/sys/kernel/debug/pmc_atom/{sleep,dev,pss}_state
Comment 2 Dainius Masiliūnas 2017-09-12 08:34:13 UTC
Created attachment 258325 [details]
lspci -v
Comment 3 Dainius Masiliūnas 2017-09-12 08:36:28 UTC
Created attachment 258327 [details]
acpidump
Comment 4 Dainius Masiliūnas 2017-09-12 08:37:25 UTC
Created attachment 258329 [details]
dsdt.dsl
Comment 6 Chen Yu 2018-03-12 00:07:50 UTC
(In reply to RussianNeuroMancer from comment #5)
> 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
Comment 7 Dainius Masiliūnas 2018-03-25 13:50:25 UTC
Tested on 4.16-rc5, and I don't see any residency in S0ix, but then I'm not sure if it's suspending altogether. dmesg shows a flurry of warnings about i2c_designware, and the device wakes up a few seconds after an attempted suspend.
Comment 8 RussianNeuroMancer 2018-08-06 13:35:50 UTC
>  I don't see any residency in S0ix
https://bugzilla.kernel.org/show_bug.cgi?id=198631#c14
Please check Linux 4.18rc8.

> and the device wakes up a few seconds after an attempted suspend
With Gnome Shell or with other DE? There is workaround in Gnome Shell: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/commit/f2ae8a3b9905cde7a9c12f78cb84689e97203380
Comment 9 Hans de Goede 2018-09-03 20:20:00 UTC
i 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, including a HP x2 210, 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

Please try a 4.18.x kernel with the above patches added and let me know here in bugzilla if that makes your HP x2 210 properly enter/use S0ix modes too.

Regards,

Hans
Comment 10 Zhang Rui 2018-09-27 07:08:57 UTC
can anyone in this thread confirm if Hans' patches solve the problem?
Comment 11 Hans de Goede 2018-09-27 10:18:24 UTC
The HP x2 210 also needs 2 pwm controller patches:

I can confirm that my patches combined with these 2:
https://patchwork.ozlabs.org/patch/968639/
https://patchwork.ozlabs.org/patch/968640/

Fix this on my own "HP Pavilion X2 10-p0XX" which is also known as the "HP x2 210 G2 Detachable PC" not sure if there is much of a difference between the "G2" version and the non "G2" version.
Comment 12 Dainius Masiliūnas 2018-09-27 21:21:20 UTC
My device is indeed the detachable HP x2 210 G2. G2 means Generation 2, but I'm not sure if non-G2 tablets even existed? Or if they were based on Cherry Trail to begin with.

Unfortunately right now I don't have the time to test the new patches on my device (and its keyboard failed for me anyway). So I guess Hans' test should suffice.
Comment 13 Robert Mast 2019-04-15 21:23:24 UTC
I own a HP x2 210 'G1', which in fact is a Cherry Trail device.
With the newer kernels in Android X86 8.1 r1 live iso and Mint 19.1 with kernel 4.20.17 cubic'd live ISO I can confirm the annoying camera light switches off.

The machine also automatically loads Hans' intel_atomisp2_pm module.

The machine doesn't even boot ok with plain Mint 19.1 with the original 4.15 kernel.

My next challenge is getting this camera light off on the Bay Trail devices like the Asus T100TA and T200TA.

I didn't see it turn off on those machines, and had to start the intel_atomisp2_pm module manually after boot, after which the light still stayed on with Mint 19.1, kernel 4.20.17 and a bootia32.efi-file on a cubic'd live ISO.

@Hans, do you have any hints on getting the intel_atomisp2_pm working on the Bay Trail Asus T100TA as well?
Comment 14 Robert Mast 2019-04-22 09:48:04 UTC
The answer to my own question for turning off the camera light on the Bay Trail Asus T100:
the intel_atomisp2_pm module on the Bay Trail currently depends on PCI device 8086:0f38, which only appears when in BIOS 'ISP PCI Device Selection' is set to 'ISP PCI Device as B0D3F0', however this setting is hidden on the ASUS T100 as it was sold for Windows only. So turning off the camera light with this 8086:0f38-module requires an AMIBCP BIOS-mod.

I wonder whether it would be possible to trigger this ISP-in-D3 logic from device 8086:0f31 instead, which is always present on a Bay Trail device and doesn't depend on the BIOS.
Comment 15 Robert Mast 2019-06-02 15:22:00 UTC
I was able to find the right offset in the NVRAM to switch the ATOMISP for Baytrail by altering some UEFI-IFR-setupmenu-extractor-code:

https://github.com/rmast/Universal-IFR-Extractor/blob/master/README.md?fbclid=IwAR2cIvxDWVt9k25WMklW5RjvRAwkMIpT18kIVHgMToRG4QKaCLFP7sfkVHM

So now I'm able to switch this ISP PCI Device Selection without fully modding the firmware on the T100TA Bay Trail laptop. This lowers the barrier for anyone trying to get this INTEL_ATOMISP2_PM-module running and switching off the camera light on bay-trail.
Comment 16 Hans de Goede 2019-06-03 06:39:48 UTC
If your goal is just to turn off the webcam LED, you likely do not need a full driver for the webam. I believe that I've read on some site about the Asus T100TA  that the LED is controlled through WMI and that blacklisting the asus-wmi driver stops the LED from turning on, note this is hearsay I did not confirm this myself.

Also this is somewhat offtopic for this bug, it might be best to file a new bug for this.
Comment 17 Hans de Goede 2020-06-03 16:08:11 UTC
(In reply to Hans de Goede from comment #16)
> If your goal is just to turn off the webcam LED, you likely do not need a
> full driver for the webam. I believe that I've read on some site about the
> Asus T100TA  that the LED is controlled through WMI and that blacklisting
> the asus-wmi driver stops the LED from turning on, note this is hearsay I
> did not confirm this myself.
> 
> Also this is somewhat offtopic for this bug, it might be best to file a new
> bug for this.

I've written a little LED driver which just controls the LED on the T100TA and which turns it off by default:

https://patchwork.kernel.org/patch/11538253/
Comment 18 youling257 2020-06-13 16:53:44 UTC
Hi, Hans, test the coming soon linux kernel 5.8rc1, no residency in S0i3 on my z3735f v891w.
S0IR Residency:	960us
S0I1 Residency:	1931552us
S0I2 Residency:	0us
S0I3 Residency:	0us
S0   Residency:	281858400us
Comment 19 youling257 2020-06-13 17:24:41 UTC
(In reply to youling257 from comment #18)
> Hi, Hans, test the coming soon linux kernel 5.8rc1, no residency in S0i3 on
> my z3735f v891w.
> S0IR Residency:       960us
> S0I1 Residency:       1931552us
> S0I2 Residency:       0us
> S0I3 Residency:       0us
> S0   Residency:       281858400us

that's because the new atomisp driver, not build it, can residency in S0i3.
Comment 20 Hans de Goede 2020-06-13 19:08:09 UTC
(In reply to youling257 from comment #19)
> that's because the new atomisp driver, not build it, can residency in S0i3.

Thanks, that is good to know. My advice would be to just not build it then, it does not work (yet) so enabling it is not really useful yet.

Note I'm working on the new/revived atomisp driver together with Mauro Chehab and I have good hope that we can actually make it work this time around, but it is going to take a while before it will actually be usable.
Comment 21 Moritz Raguschat 2021-01-25 00:53:43 UTC
(In reply to Hans de Goede from comment #20)
>
> Note I'm working on the new/revived atomisp driver together with Mauro
> Chehab and I have good hope that we can actually make it work this time
> around, but it is going to take a while before it will actually be usable.

That is interesting to hear. Is there any progress on this?
And where can I actually find the old "non-dummy" version that did not work? I guess it's still archived somewhere?
Comment 22 Hans de Goede 2021-01-25 08:44:23 UTC
(In reply to Moritz Raguschat from comment #21)
> > Note I'm working on the new/revived atomisp driver
> That is interesting to hear. Is there any progress on this?

I'm afraid that we are stuck again, sorry.

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