Bug 196915

Created attachment 258323 [details]
/sys/kernel/debug/pmc_atom/{sleep,dev,pss}_state

Created attachment 258325 [details]
lspci -v

Created attachment 258327 [details]
acpidump

Created attachment 258329 [details]
dsdt.dsl

https://www.dpin.de/nf/finally-s0i3-is-there-thinkpad-tablet-10-sleeps-deeply-with-linux-kernel-4-15rc/

(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

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.

>  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

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

can anyone in this thread confirm if Hans' patches solve the problem?

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.

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.

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?

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.

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.

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.

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

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

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

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

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

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