Bug 201579 - HP Elite x2 1013 G3 unable to enter S0ix
Summary: HP Elite x2 1013 G3 unable to enter S0ix
Status: RESOLVED CODE_FIX
Alias: None
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Rafael J. Wysocki
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-31 08:49 UTC by RussianNeuroMancer
Modified: 2019-10-01 06:30 UTC (History)
8 users (show)

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


Attachments
dmesg of LTR ignore script run (84.39 KB, text/plain)
2018-10-31 08:49 UTC, RussianNeuroMancer
Details
pch_ip_power_gating_status output (2.22 KB, text/plain)
2018-10-31 08:50 UTC, RussianNeuroMancer
Details
lspci (2.72 KB, text/plain)
2018-11-04 05:51 UTC, RussianNeuroMancer
Details
dmesg of suspend without audio and thunderbolt (67.23 KB, text/plain)
2018-11-09 11:30 UTC, RussianNeuroMancer
Details
pch_ip_power_gating_status output (2) (2.24 KB, text/plain)
2018-11-16 05:37 UTC, RussianNeuroMancer
Details
sleepstudy report (195.83 KB, text/html)
2018-11-22 09:25 UTC, RussianNeuroMancer
Details
IPU Driver patches (297.84 KB, application/x-tar)
2018-12-14 19:36 UTC, Rajneesh Bhardwaj
Details
Suspend with Linux 5.0rc4 with " ICL support and other enhancements for PMC Core" patches and "" (84.32 KB, text/plain)
2019-02-03 10:58 UTC, RussianNeuroMancer
Details
working config files (211.96 KB, text/x-mpsub)
2019-02-04 03:47 UTC, Rajneesh Bhardwaj
Details
working config files (216.18 KB, text/plain)
2019-02-04 03:48 UTC, Rajneesh Bhardwaj
Details

Description RussianNeuroMancer 2018-10-31 08:49:02 UTC
Created attachment 279273 [details]
dmesg of LTR ignore script run

Hello!

I trying to debug power consumption in S0ix on HP Elite x2 1013 G3 (with NVMe) by following this guide: https://01.org/blogs/qwang59/2018/how-achieve-s0ix-states-linux

I find that PC10 do work, according to both of powertop and /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us and residency level is high (around 80-90% in short test runs, couple of minutes long). That was tested with both of tlp and powertop --auto-tune.

As for opportunistc sleep, I got PC7 at best, with screen in DPMS and no running background software besides Gnome Shell and powertop in Gnome Terminal. /sys/kernel/debug/pmc_core/pch_ip_power_gating_status output during idle with screen off is attached.

Then I got stuck at /sys/kernel/debug/pmc_core/slp_s0_residency_usec - it's always zero.

Debug data:

GFX check:
~# cat /sys/class/drm/card0/power/rc6_residency_ms
1325413
~# cat /sys/kernel/debug/dri/0/i915_dmc_info
fw loaded: yes
path: i915/kbl_dmc_ver1_04.bin
version: 1.4
DC3 -> DC5 count: 249
DC5 -> DC6 count: 176
program base: 0x09004040
ssp base: 0x00002fc0
htp: 0x00b40068
~$ dmesg | grep i915
[    5.359747] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[    5.361077] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    6.052920] [drm] Initialized i915 1.6.0 20180719 for 0000:00:02.0 on minor 0
[    6.060562] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[    7.212506] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device

dp_debug_messages:
[ 1724.022528] ACPI: \_PR_.PR00: LPI: Device not power manageable
[ 1724.022534] ACPI: \_PR_.PR01: LPI: Device not power manageable
[ 1724.022537] ACPI: \_PR_.PR02: LPI: Device not power manageable
[ 1724.022541] ACPI: \_PR_.PR03: LPI: Device not power manageable
[ 1724.022545] ACPI: \_SB_.PCI0.GFX0: LPI: Device not power manageable
[ 1724.022556] ACPI: \_SB_.PCI0.RP05.PXSX: LPI: Device not power manageable
[ 1724.022560] ACPI: \_SB_.PCI0.RP09.PXSX: LPI: Device not power manageable
[ 1724.022563] ACPI: \_SB_.PCI0.ISP0: LPI: Device not power manageable

Here is results of running script from https://bugzilla.kernel.org/show_bug.cgi?id=199689#c38 
LTR ignore for 0
rtcwake: assuming RTC uses UTC ...
rtcwake: wakeup from "freeze" using /dev/rtc0 at Wed Oct 31 08:27:44 2018
residency is 19686762
Residency is non zero!

Relevant dmesg is attached (I run script two times, second time with LANG=C to got non-localized output that I can post here).

I also find that powertop is always report low power consumption (around two hundreds milliwatts) and high estimated battery time (more than 150 hours). I not sure if this is kernel issue or powertop issue - where I can report this?

acpidump and dsdt.dsl is available here: https://bugzilla.kernel.org/show_bug.cgi?id=201575
Comment 1 RussianNeuroMancer 2018-10-31 08:50:03 UTC
Created attachment 279275 [details]
pch_ip_power_gating_status output
Comment 2 Rajneesh Bhardwaj 2018-11-02 06:28:01 UTC
Based on pch_ip_power_gating_status i can see that there may be two possible reasons.

1. Can you please completely disable audio ( in HW / BIOS / or via Driver unloading) and test S0ix again.
2. What is connected to South Port A as SPA IP is on. SPA is PCI Exp root port A, so you might have either Disk / Wifi there possibly. That may be another reason.
Comment 3 RussianNeuroMancer 2018-11-04 05:51:20 UTC
Created attachment 279307 [details]
lspci

Thanks for looking into this issue!

> Can you please completely disable audio ( in HW / BIOS / or via Driver
> unloading) and test S0ix again.

I tried to disable audio in BIOS but this doesn't make S0ix works. 

> you might have either Disk / Wifi there possibly

I also tried to disable audio, WiFi, WWAN and cameras in BIOS but this also doesn't help. Not sure what I can do about NVMe disk.

>  SPA is PCI Exp root port A

Maybe there is way to find which device it is from lspci or dsdt.dsl?  dsdt.dsl is here https://bugzilla.kernel.org/show_bug.cgi?id=201575 and lspci is attached.
Comment 4 Rajneesh Bhardwaj 2018-11-05 21:47:03 UTC
Would you have access to the device's schematics somehow? If we have schematics we can easily see whats connected to which root port.
Comment 5 RussianNeuroMancer 2018-11-08 06:09:45 UTC
Unfortunately, I doesn't have access to the device's schematics.
Comment 6 Rajneesh Bhardwaj 2018-11-08 10:06:58 UTC
  Is it possible to connect to a normal SATA disk once (after removing NVME) for testing? When using SATA we need to make sure it supports devslp / slumber mode.

Also i would like to know whether the device came with Windows and you erased it and flashed linux on it? If so, does it by default support Modern connected standby on windows? I am asking this because some BIOS vendors may disable S0ix (Connected Standby).

I am still strongly suspecting Audio and NVME (_most_ likely SPA) but can you also try once disabling Thunderbolt and Audio in BIOS?

Any possibility of;
1. Remote sharing (ssh, somehow?)
2. You compile, flash custom kernel.
Comment 7 RussianNeuroMancer 2018-11-09 11:30:13 UTC
Created attachment 279389 [details]
dmesg of suspend without audio and thunderbolt

Hello!

> I am still strongly suspecting Audio and NVME (_most_ likely SPA) but can you
> also try once disabling Thunderbolt and Audio in BIOS?

I tried to disable both of Thunderbolt and audio in BIOS. You can verify in attached dmesg that snd_hda_codec_conexant and thunderbolt driver doesn't load, as expected. However, this does not improve situation - PC10 can be reached as before, but slp_s0_residency_usec remain zero after suspend.

> Is it possible to connect to a normal SATA disk once (after removing NVME)
> for testing? When using SATA we need to make sure it supports devslp /
> slumber mode.

This device is a tablet, so it doesn't have SATA ports. Only possible way for attaching SATA device is via external USB-SATA adapter. Is it make sense to use USB-SATA adapter in this case, or USB-SATA adapter would keep system from entering S0ix?

Also, you may want to check Bug 201587 about similar issue on HP EliteBook Folio G1 - this laptop use SATA by default, yet it also have same issue with S0ix.

> Also i would like to know whether the device came with Windows and you erased
> it and flashed linux on it? 

Correct, device came with Windows and then it was replaced with Linux.

> If so, does it by default support Modern connected standby on windows? 

Yes, Modern / Connected Standby is supported. 

> I am asking this because some BIOS vendors may disable S0ix (Connected
> Standby).

In the past HP provide two checkboxes that allow to enable or disable Connected Standby and Deep Sleep (S3) in BIOS. For example on HP EliteBook Folio G1 from Bug 201587 option for enabling and disabling Connected Standby is present and enabled.

On HP Elite x2 1013 G3 from this bugreport there is BIOS option that allow to enable or disable Deep Sleep, while Connected Standy seems like always enabled by firmware without option that would allow to disable it. At least Linux use s2idle by default on this tablet, which probably mean that it advertised as supported and recommended by firmware, right? 

Photo of options available on HP Elite x2 1013 G3: https://i.imgur.com/EENTfIA.jpg

> Any possibility of;
> 1. Remote sharing (ssh, somehow?)
> 2. You compile, flash custom kernel.

Both of this option is possible, but second is preferred for me, because this device is act as my main laptop right now.
Comment 8 Rajneesh Bhardwaj 2018-11-14 07:32:14 UTC
I have got one hp-elite-x2-1013-g3, remotely setup but on my machine i see CSME is always on which is not the case on your machine.

1. Can you please share 
 cat /sys/kernel/debug/pmc_core/pll_status
 cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status and 
 pch_ip_power_gating_status  again, please?

2. Did you please share screen shots of your BIOS screens.
Comment 9 RussianNeuroMancer 2018-11-16 05:37:47 UTC
Created attachment 279469 [details]
pch_ip_power_gating_status output (2)

Hello!

> remotely setup but on my machine i see CSME is always on which is not the
> case on your machine.

I don't know which kernel version remote machine run, but I can tell that on my device for example C-State C10 wasn't available before Linux 4.19.0, so I guess there could be other PM related issues on older kernels. Maybe remote machine run on Linux 4.18 or older? 

> Can you please share 

Sure, pch_ip_power_gating_status output is attached, and everything else is here. I will upload photos later today.

~# cat /sys/kernel/debug/pmc_core/pll_status
MIPI PLL                        	State: Idle
GEN2 USB2PCIE2 PLL              	State: Active
DMIPCIE3 PLL                    	State: Active
SATA PLL                        	State: Idle

~# cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status
MPHY CORE LANE 0                	State: Power gated
MPHY CORE LANE 1                	State: Power gated
MPHY CORE LANE 2                	State: Power gated
MPHY CORE LANE 3                	State: Power gated
MPHY CORE LANE 4                	State: Not power gated
MPHY CORE LANE 5                	State: Not power gated
MPHY CORE LANE 6                	State: Not power gated
MPHY CORE LANE 7                	State: Not power gated
MPHY CORE LANE 8                	State: Power gated
MPHY CORE LANE 9                	State: Power gated
MPHY CORE LANE 10               	State: Power gated
MPHY CORE LANE 11               	State: Power gated
MPHY CORE LANE 12               	State: Power gated
MPHY CORE LANE 13               	State: Power gated
MPHY CORE LANE 14               	State: Power gated
MPHY CORE LANE 15               	State: Power gated
Comment 10 Rajneesh Bhardwaj 2018-11-16 06:21:32 UTC
In the latest PCH IP power gate status, i see now CSME is power gated. What has changed now?

When we used Windows image on the same machine, we can only see PC8. So, can you please confirm if you can see S0ix on Windows. We need to rule out any BIOS issue here as i see many MPHY Lanes are not power gated.
Comment 11 RussianNeuroMancer 2018-11-16 08:18:54 UTC
BIOS photos: https://yadi.sk/d/xEtS5lXk8kKawg

> In the latest PCH IP power gate status, i see now CSME is power gated. What
> has changed now?

Please clarify, isn't previous pch_ip_power_gating_status output and current one is exactly the same? Seems like there is no changes, as you can see:

https://bugzilla.kernel.org/attachment.cgi?id=279275
https://bugzilla.kernel.org/attachment.cgi?id=279469

> So, can you please confirm if you can see S0ix on Windows.

Okay, I will check this, but this will take a few days, as I need to finish my current job task first, so I can backup Linux and load Windows on machine.

Is there any other useful information that I could gather from Windows setup, that could be useful for further issue debug? 

> When we used Windows image on the same machine, we can only see PC8.

What tools would you recommend for verifying this? Is "powercfg /a" and "powercfg sleepstudy" is sufficient? I guess I should leave device in suspend for at least couple of hours before generating report, but it's better to leave it for a night or suspend duration doesn't make a difference for report usefulness?

Is there maybe some tools from Intel for Windows that could provide more info about S0ix status?
Comment 12 Rajneesh Bhardwaj 2018-11-16 10:36:41 UTC
(In reply to RussianNeuroMancer from comment #11)
> BIOS photos: https://yadi.sk/d/xEtS5lXk8kKawg
> 
> > In the latest PCH IP power gate status, i see now CSME is power gated. What
> > has changed now?
> 
> Please clarify, isn't previous pch_ip_power_gating_status output and current
> one is exactly the same? Seems like there is no changes, as you can see:
> 
> https://bugzilla.kernel.org/attachment.cgi?id=279275
> https://bugzilla.kernel.org/attachment.cgi?id=279469
> 

Yes, is is same. On my setup CSME isnt getting off so i got confused.

> > So, can you please confirm if you can see S0ix on Windows.
> 
> Okay, I will check this, but this will take a few days, as I need to finish
> my current job task first, so I can backup Linux and load Windows on machine.
> 
> Is there any other useful information that I could gather from Windows
> setup, that could be useful for further issue debug? 
> 
> > When we used Windows image on the same machine, we can only see PC8.
> 
> What tools would you recommend for verifying this? Is "powercfg /a" and
> "powercfg sleepstudy" is sufficient? I guess I should leave device in
> suspend for at least couple of hours before generating report, but it's
> better to leave it for a night or suspend duration doesn't make a difference
> for report usefulness?
> 
> Is there maybe some tools from Intel for Windows that could provide more
> info about S0ix status?

I will check internally if there is any better tool but you can try Socwatch for windows as well.
Comment 13 RussianNeuroMancer 2018-11-22 06:25:47 UTC
I restore original Windows 10 backup created after device purchase and at least according to "powercfg sleepstudy" SoC do enter C10 C-State, in half hour suspend testing battery consumption was below 1% (battery level was the same before suspend and after wakeup). It's important to notice that I don't let system perform updates before creating backup and after restoring backup, so it's 100% original drivers shipped my manufacturer, not newer drivers from HP web-site or Windows Update (which could contain some regressions).

Later today I will suspend device for three hours and see how much battery will be consumed. After four hours of sleep it hibernate automatically (at least this is what I see in sleepstudy report) so there is no much point in testing it for a longer periods of time, so three hours probably should be sufficient. 

> I will check internally if there is any better tool but you can try Socwatch
> for windows as well.

I couldn't use socwatch because Intel System Studio 2019 free license doesn't let socwatch installation. At least this is what was said in error message when I select only socwatch in Intel System Studio 2019 installer. Is there other tools that support C-State monitoring of modern Intel's SoC? 

While Windows is still installed I would like to provide as much information as possible. So please let me know if there is anything else I could check before restoring Linux back.
Comment 14 RussianNeuroMancer 2018-11-22 09:25:38 UTC
Created attachment 279609 [details]
sleepstudy report

After three hours long suspend just 1% of battery was consumed. Relevant powercfg report is attached.
Comment 15 Rajneesh Bhardwaj 2018-11-26 08:53:50 UTC
MPHY Lanes 4-7 are related to Thunderbolt IP on your device. With recent 4.20-rc4 kernel, you should see them power gated. 

MPHY CORE LANE 0                        State: Power gated
MPHY CORE LANE 1                        State: Power gated
MPHY CORE LANE 2                        State: Not power gated
MPHY CORE LANE 3                        State: Power gated
MPHY CORE LANE 4                        State: Power gated
MPHY CORE LANE 5                        State: Power gated
MPHY CORE LANE 6                        State: Power gated
MPHY CORE LANE 7                        State: Power gated
MPHY CORE LANE 8                        State: Power gated
MPHY CORE LANE 9                        State: Power gated
MPHY CORE LANE 10                       State: Power gated
MPHY CORE LANE 11                       State: Power gated
MPHY CORE LANE 12                       State: Power gated
MPHY CORE LANE 13                       State: Power gated
MPHY CORE LANE 14                       State: Power gated
MPHY CORE LANE 15                       State: Power gated

I would like to revisit debugging on your machine after the MPHY issue is fixed so please update to rc4 first.

On my test device, now i am suspecting Camera as a potential blocker for S0ix. MPHY lanes are power gated now on my machine. 

While testing, please ensure you do not keep any Thunderbolt device (or any type c ) connected.
Comment 16 RussianNeuroMancer 2018-11-27 06:32:22 UTC
> I would like to revisit debugging on your machine after the MPHY issue is
> fixed so please update to rc4 first.

Sure, here is  /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status content with Linux 4.20rc4: 

MPHY CORE LANE 0                	State: Power gated
MPHY CORE LANE 1                	State: Power gated
MPHY CORE LANE 2                	State: Power gated
MPHY CORE LANE 3                	State: Power gated
MPHY CORE LANE 4                	State: Power gated
MPHY CORE LANE 5                	State: Power gated
MPHY CORE LANE 6                	State: Power gated
MPHY CORE LANE 7                	State: Power gated
MPHY CORE LANE 8                	State: Power gated
MPHY CORE LANE 9                	State: Power gated
MPHY CORE LANE 10               	State: Power gated
MPHY CORE LANE 11               	State: Power gated
MPHY CORE LANE 12               	State: Power gated
MPHY CORE LANE 13               	State: Power gated
MPHY CORE LANE 14               	State: Power gated
MPHY CORE LANE 15               	State: Power gated

(Sometimes LANE 2 switch between "Not power gated" and "Power gated".)

After suspend:

~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
346273536
~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
0
~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
0

> On my test device, now i am suspecting Camera as a potential blocker for
> S0ix.

Test above was run with disabled Front and Rear Cameras in BIOS. I also repeat test with enabled Cameras and get same result. 

Or under "Camera" you mean ipu3 doesn't power down?
Comment 17 Rajneesh Bhardwaj 2018-11-28 08:33:45 UTC
Good to know that the MPHY Lanes are now gated so we move one step closer.
Dont worry about Lane 2 behavior sometime, it can happen if you have a USB TC hub and some device connected.

We have the driver for ipu-cio in Linux mainline but no driver is present yet for IMGU i.e. PCI device 00:05.0. Some patches are present in media tree https://patchwork.kernel.org/project/linux-media/list/?series=36183  but even with those, i see some issues w.r.t S0ix, perhaps some clocks are not shutdown cleanly. I am exploring it next.

right now, its difficult to say whether its a kernel issue or some HP bios, missing asl  implementation. 

While this is being debugged, if battery drain is an issue for you, try switching to S3 in the meantime, it works on this device.
Comment 18 Rajneesh Bhardwaj 2018-11-28 08:34:09 UTC
Good to know that the MPHY Lanes are now gated so we move one step closer.
Dont worry about Lane 2 behavior sometime, it can happen if you have a USB TC hub and some device connected.

We have the driver for ipu-cio in Linux mainline but no driver is present yet for IMGU i.e. PCI device 00:05.0. Some patches are present in media tree https://patchwork.kernel.org/project/linux-media/list/?series=36183  but even with those, i see some issues w.r.t S0ix, perhaps some clocks are not shutdown cleanly. I am exploring it next.

right now, its difficult to say whether its a kernel issue or some HP bios, missing asl  implementation. 

While this is being debugged, if battery drain is an issue for you, try switching to S3 in the meantime, it works on this device.
Comment 19 Rajneesh Bhardwaj 2018-11-28 08:50:41 UTC
Just curious to know BIOS version on your device, can you also attach a screenshot of Advance System Information page that tell BIOS/CPU etc?
Comment 20 RussianNeuroMancer 2018-11-28 09:03:22 UTC
> but even with those, i see some issues w.r.t S0ix, perhaps some clocks are
> not shutdown cleanly. I am exploring it next.

Again, thank you for looking into this issue :)

> While this is being debugged, if battery drain is an issue for you, try
> switching to S3 in the meantime, it works on this device.

On this particular device - yes, I can use S3 for now. By the way, I wonder what you think about Bug 201575 which is specific to Connected Standby? There is opinion that this is Intel EC firmware issue, yet I never seen this bug in Windows. 

Also I want to note, that while I can use S3 on HP Elite x2 1013 G3, for HP EliteBook Folio G1 from Bug 201587 this is not an option, unfortunately. While HP EliteBook Folio G1 BIOS let user disable Connected Standby and enable Deep Sleep, Deep Sleep is unusable because laptop wakeup from S3 almost immediately after suspend. This doesn't happen when I do suspend freeze instead of S3, so using Connected Standby is necessary for this laptop, but battery drain in suspend freeze is also high.

> Just curious to know BIOS version on your device, can you also attach a
> screenshot of Advance System Information page that tell BIOS/CPU etc?

BIOS version is  BIOS Q87 Ver. 01.05.00 10/03/2018, and CPU model is Intel Core iy-8550U. 

I will upload photo of Advance System Information in BIOS later today.
Comment 21 RussianNeuroMancer 2018-11-28 11:37:33 UTC
Advance System Information page photos uploaded: https://yadi.sk/d/xEtS5lXk8kKawg (000-1.jpg, 000-2.jpg, 000-3.jpg).
Comment 22 Rajneesh Bhardwaj 2018-12-07 21:00:45 UTC
I am debugging this issue and will post an update shortly.
Comment 23 Rajneesh Bhardwaj 2018-12-14 19:36:13 UTC
Created attachment 280025 [details]
IPU Driver patches
Comment 24 Rajneesh Bhardwaj 2018-12-14 19:49:45 UTC
Updates on this issue:

Rootcause => CSI MIPI Camera and some platform clocks block S0ix on this machine.

Linux CSI MIPI Camera stack is not yet fully ready for Linux, some patches are in mainline already while some are being reviewed. https://git.linuxtv.org/sailus/media_tree.git/log/?h=ipu3-v7

Since Linux user-space also lacks support for libraries/apps to make use of such camera, its better to keep them disabled in the BIOS but the BIOS on this machine doesn't properly disable Camera IPs/PCI devices i.e. 00:05.0 and 00:14.3 but it just disabled I2C camera sensors which is not enough to make system enter S0ix. We informed about this to HP and there is a hope to get it fixed in a future BIOS update. I will keep you posted, though can't comment on their timelines or commitment to deliver the requested changes. Maybe you can ask them directly and point to this BZ so they can reach out to us via another channel too if they'd like to.

Here is a list of patches that you'll need to properly suspend Camera IPs if BIOS is not available.
Mandataory upto : 9d240ec0729a ipu3-cio2: Allow probe to succeed if there are no sensors connected, others above this one are optional.

e1447e361bb1 (HEAD -> imgu) platform/x86: intel_telemetry: convert to DEFINE_SHOW_ATTRIBUTE
578f29772469 platform/x86: intel_pmc_core: convert to DEFINE_SHOW_ATTRIBUTE
4c7795fd3c2e platform/x86: intel_pmc_core: Decode Snoop / Non Snoop LTR
9e25c08add3e platform/x86: intel_pmc_core: Fix LTR IGNORE Max offset
6df132773653 platform/x86: intel_pmc_core: Show Latency Tolerance info
9d240ec0729a ipu3-cio2: Allow probe to succeed if there are no sensors connected
0ca1429ebe6e v4l: Add support for V4L2_BUF_TYPE_META_OUTPUT
9d7c88f8939b intel-ipu3: add dual pipe support
83c0496bd49c intel-ipu3: Add imgu top level pci device driver
f15da4766c79 intel-ipu3: Add v4l2 driver based on media framework
de2fbb2d2e3f intel-ipu3: Add css pipeline programming
3848b666dfe2 intel-ipu3: css: Initialize css hardware
7592234cc4a6 intel-ipu3: css: Compute and program ccs
01812ebd0dd3 intel-ipu3: css: Add static settings for image pipeline
262fd9096bac intel-ipu3: css: Add support for firmware management
a7e54796e0ee intel-ipu3: css: Add dma buff pool utility functions
0b459f0243fe intel-ipu3: Implement DMA mapping functions
4bf5b45b2ba5 intel-ipu3: mmu: Implement driver
32647abc6f50 intel-ipu3: abi: Add structs
039a16903a39 intel-ipu3: abi: Add register definitions and enum
b6a44999799a v4l: Add Intel IPU3 meta data uAPI
77d5c7a65c7a doc-rst: Add Intel IPU3 documentation
4a030f4393be v4l: Add Intel IPU3 meta buffer formats
2e6e902d1850 (tag: v4.20-rc4, origin/master, origin/HEAD,master) Linux 4.20-rc4


I am attaching a tarball here for your convenience.

Then make sure that the IPU FW is present in /lib/firmware. On Ubuntu, it may be elsewhere so please make sure to replicate like below.

/lib/firmware# ls -la ipu3-fw.bin
lrwxrwxrwx 1 root root 52 Nov 26 23:57 ipu3-fw.bin -> irci_irci_ecr-master_20161208_0213_20170112_1500.bin

With the above config, you should not see any camera FW load errors at boot time in dmesg and the PCI devices 00:05.0 and 00:14.4 should show camera devices are runtime suspended.

cat /sys/bus/pci/devices/0000\:00\:05.0/power/runtime_status
suspended
cat /sys/bus/pci/devices/0000\:00\:14.3/power/runtime_status
suspended


However, even after all this, there is still one more thing remaining for which we need BIOS support and that is related some platform Clock shutdown.
Comment 25 RussianNeuroMancer 2018-12-15 14:44:24 UTC
Hello!

> I am attaching a tarball here for your convenience.

Thanks!

> However, even after all this, there is still one more thing remaining for
> which we need BIOS support and that is related some platform Clock shutdown.

I will try to apply this patches on top of Linux 4.20rc7 next week, but as I understand, I shouldn't see see any changes in power consumption in S0, just runtime_status suspended right for this two PCI devices? 

> PCI devices 00:05.0 and 00:14.4 should show camera devices are runtime
> suspended

Regardless of Camera status in BIOS, or Camera should be disabled in order to get runtime_status suspended?

> Maybe you can ask them directly and point to this BZ so they can reach out to
> us via another channel too if they'd like to.

I will try HP Chat support on Monday. Besides Chat support there is just HP forums and phone number, I can't find support e-mail. So from all three, I guess Chat is best available option.

> Then make sure that the IPU FW is present in /lib/firmware. On Ubuntu, it may
> be elsewhere so please make sure to replicate like below.

On Ubuntu firmware is here:

/lib/firmware/intel$ ls -la ipu3-fw.bin
lrwxrwxrwx 1 root root 52 Nov  6 22:30 ipu3-fw.bin -> irci_irci_ecr-master_20161208_0213_20170112_1500.bin

As I understand, I should create symlink /lib/firmware/ipu3-fw.bin to /lib/firmware/intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin
Comment 26 Rajneesh Bhardwaj 2018-12-15 17:42:56 UTC
(In reply to RussianNeuroMancer from comment #25)
> Hello!
> 
> > I am attaching a tarball here for your convenience.
> 
> Thanks!
> 
> > However, even after all this, there is still one more thing remaining for
> > which we need BIOS support and that is related some platform Clock
> shutdown.
> 
> I will try to apply this patches on top of Linux 4.20rc7 next week, but as I
> understand, I shouldn't see see any changes in power consumption in S0, just
> runtime_status suspended right for this two PCI devices? 
> 

I haven't measured but it should improve power.

> > PCI devices 00:05.0 and 00:14.4 should show camera devices are runtime
> > suspended
> 
> Regardless of Camera status in BIOS, or Camera should be disabled in order
> to get runtime_status suspended?
> 
 
With these patches, camera can be left _ON_ in BIOS. 

> > Maybe you can ask them directly and point to this BZ so they can reach out
> to
> > us via another channel too if they'd like to.
> 
> I will try HP Chat support on Monday. Besides Chat support there is just HP
> forums and phone number, I can't find support e-mail. So from all three, I
> guess Chat is best available option.

Sounds good.

> 
> > Then make sure that the IPU FW is present in /lib/firmware. On Ubuntu, it
> may
> > be elsewhere so please make sure to replicate like below.
> 
> On Ubuntu firmware is here:
> 
> /lib/firmware/intel$ ls -la ipu3-fw.bin
> lrwxrwxrwx 1 root root 52 Nov  6 22:30 ipu3-fw.bin ->
> irci_irci_ecr-master_20161208_0213_20170112_1500.bin
> 
> As I understand, I should create symlink /lib/firmware/ipu3-fw.bin to
> /lib/firmware/intel/irci_irci_ecr-master_20161208_0213_20170112_1500.bin


Yes, that's what i meant. At boot time, dmesg should say FW loaded properly instead of an error related to FW load failure.
Comment 27 RussianNeuroMancer 2018-12-17 16:18:09 UTC
I end up posting this information on HP forum, as Chat support wasn't available due to what seems like server side issue, and MyHPSupport portal wasn't available due to probably some issue specific to my account. 

https://h30434.www3.hp.com/t5/Notebook-Hardware-and-Upgrade-Questions/Camera-checkbox-in-BIOS-on-HP-Elite-x2-1013-G3-keep-Intel/m-p/6939946#M490474

I not tested patchset yet, will try to do so tomorrow.

> I haven't measured but it should improve power.

By the way, is there way to measure power consumption on this device?
powertop doesn't report correct values.
Comment 28 Rajneesh Bhardwaj 2018-12-18 10:47:20 UTC
(In reply to RussianNeuroMancer from comment #27)
> I end up posting this information on HP forum, as Chat support wasn't
> available due to what seems like server side issue, and MyHPSupport portal
> wasn't available due to probably some issue specific to my account. 
> 
> https://h30434.www3.hp.com/t5/Notebook-Hardware-and-Upgrade-Questions/Camera-
> checkbox-in-BIOS-on-HP-Elite-x2-1013-G3-keep-Intel/m-p/6939946#M490474
> 
> I not tested patchset yet, will try to do so tomorrow.
> 
> > I haven't measured but it should improve power.
> 
> By the way, is there way to measure power consumption on this device?
> powertop doesn't report correct values.

you can try cat /sys/class/power_supply/BAT0/charge_now to check power at battery out level and for SoC power you can refer to /sys/class/powercap/intel-rapl..<domain0>\energy_uj but for your usecase, you should read the platform power i.e. BAT0.
Comment 29 RussianNeuroMancer 2018-12-20 04:20:12 UTC
After installing patched kernel ipu3-imgu is loading, 00:05.0 and 00:14.4 devices runtime_status is suspended. Log:  

~$ dmesg | grep ipu
[    5.259167] ipu3-imgu 0000:00:05.0: enabling device (0000 -> 0002)
[    5.259376] ipu3-imgu 0000:00:05.0: device 0x1919 (rev: 0x1)
[    5.259443] ipu3-imgu 0000:00:05.0: physical base address 0x0000001ffb000000, 4194304 bytes
[    5.331649] ipu3-cio2 0000:00:14.3: enabling device (0000 -> 0002)
[    5.331895] ipu3-cio2 0000:00:14.3: device 0x9d32 (rev: 0x1)
[    5.335007] ipu3-cio2 0000:00:14.3: Entity type for entity ipu3-csi2 0 was not initialized!
[    5.335082] ipu3-cio2 0000:00:14.3: Entity type for entity ipu3-csi2 1 was not initialized!
[    5.335140] ipu3-cio2 0000:00:14.3: Entity type for entity ipu3-csi2 2 was not initialized!
[    5.335191] ipu3-cio2 0000:00:14.3: Entity type for entity ipu3-csi2 3 was not initialized!
[    5.377774] ipu3-imgu 0000:00:05.0: loaded firmware version irci_irci_ecr-master_20161208_0213_20170112_1500, 17 binaries, 1212984 bytes

> but for your usecase, you should read the platform power i.e. BAT0.

Isn't there is only current charge level, which change slowly and not provide information about current consumption level? Or I missing something?
Comment 30 RussianNeuroMancer 2018-12-20 04:22:13 UTC
Almost forgot to mention: first patch inside ipu_patches.tar was corrupted, so I download it from https://git.linuxtv.org/sailus/media_tree.git/commit/?h=ipu3-v7&id=194b8716c41f80ddba226f8f28d39796ed33c41c
Comment 31 Caroline Webb 2019-01-09 09:38:20 UTC
Thanks for letting us know this bug of HP Elite x2 1013 G3 which is unable to enter S0ix with attachments to understand the bug and what could be the solution for it.

Caroline,
http://www.personalstatementfolks.co.uk/
Comment 32 Ida Wallace 2019-01-11 12:36:46 UTC
Found many solutions about this bugs and links for reference for other developers who are working on the upstream Linux kernels.

Ida,
http://www.assignmenthelpfolks.com/
Comment 33 Rajneesh Bhardwaj 2019-02-01 07:42:07 UTC
Hi RussianNeuroMancer,
 Can you please try this patch series https://patchwork.kernel.org/project/platform-driver-x86/list/?series=74547 on top of this https://patchwork.kernel.org/patch/10714257/ 

I have tested this with official HP Bios and this series on Linux 5.0 and S0ix works fine.

Please try.

Hope it helps you.

Thanks
Rajneesh
Comment 34 RussianNeuroMancer 2019-02-01 08:46:23 UTC
> Can you please try this patch series

Sure, I will be able to build Linux 5.0 with this patches tomorrow.

> I have tested this with official HP Bios and this series on Linux 5.0 and
> S0ix works fine.

Upon testing this patches did you encounter bug 201575 or you didn't seen it?
Comment 35 RussianNeuroMancer 2019-02-03 10:58:45 UTC
Created attachment 280935 [details]
Suspend with Linux 5.0rc4 with "	ICL support and other enhancements for PMC Core" patches and ""

I applied https://patchwork.kernel.org/patch/10714257/ manually and applied https://patchwork.kernel.org/project/platform-driver-x86/list/?series=74547 by feeding this file https://patchwork.kernel.org/series/74547/mbox/ to patch utility (judging by output it's seems like it find all diffs inside this mbox and applied them accordingly). That all was on top of Linux 5.0-rc4 sources.

Unfortunately, S0ix hasn't been reached:

~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
8020439170
~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
0
~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
0

More info:

~# cat /sys/kernel/debug/pmc_core/pch_ip_power_gating_status
PCH IP: 0  - PMC                             	State: On
PCH IP: 1  - OPI-DMI                         	State: On
PCH IP: 2  - SPI / eSPI                      	State: On
PCH IP: 3  - XHCI                            	State: On
PCH IP: 4  - SPA                             	State: Off
PCH IP: 5  - SPB                             	State: On
PCH IP: 6  - SPC                             	State: On
PCH IP: 7  - GBE                             	State: Off
PCH IP: 8  - SATA                            	State: Off
PCH IP: 9  - HDA-PGD0                        	State: On
PCH IP: 10 - HDA-PGD1                        	State: Off
PCH IP: 11 - HDA-PGD2                        	State: Off
PCH IP: 12 - HDA-PGD3                        	State: Off
PCH IP: 13 - RSVD                            	State: Off
PCH IP: 14 - LPSS                            	State: Off
PCH IP: 15 - LPC                             	State: Off
PCH IP: 16 - SMB                             	State: Off
PCH IP: 17 - ISH                             	State: On
PCH IP: 18 - P2SB                            	State: Off
PCH IP: 19 - DFX                             	State: Off
PCH IP: 20 - SCC                             	State: Off
PCH IP: 21 - RSVD                            	State: Off
PCH IP: 22 - FUSE                            	State: On
PCH IP: 23 - CAMERA                          	State: Off
PCH IP: 24 - RSVD                            	State: Off
PCH IP: 25 - USB3-OTG                        	State: Off
PCH IP: 26 - EXI                             	State: Off
PCH IP: 27 - CSE                             	State: Off
PCH IP: 28 - CSME_KVM                        	State: Off
PCH IP: 29 - CSME_PMT                        	State: Off
PCH IP: 30 - CSME_CLINK                      	State: Off
PCH IP: 31 - CSME_PTIO                       	State: Off
PCH IP: 32 - CSME_USBR                       	State: Off
PCH IP: 33 - CSME_SUSRAM                     	State: Off
PCH IP: 34 - CSME_SMT                        	State: Off
PCH IP: 35 - RSVD                            	State: Off
PCH IP: 36 - CSME_SMS2                       	State: Off
PCH IP: 37 - CSME_SMS1                       	State: Off
PCH IP: 38 - CSME_RTC                        	State: Off
PCH IP: 39 - CSME_PSF                        	State: Off

~# cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status 
MPHY CORE LANE 0                	State: Power gated
MPHY CORE LANE 1                	State: Power gated
MPHY CORE LANE 2                	State: Not power gated
MPHY CORE LANE 3                	State: Power gated
MPHY CORE LANE 4                	State: Power gated
MPHY CORE LANE 5                	State: Power gated
MPHY CORE LANE 6                	State: Power gated
MPHY CORE LANE 7                	State: Power gated
MPHY CORE LANE 8                	State: Not power gated
MPHY CORE LANE 9                	State: Power gated
MPHY CORE LANE 10               	State: Power gated
MPHY CORE LANE 11               	State: Power gated
MPHY CORE LANE 12               	State: Not power gated
MPHY CORE LANE 13               	State: Not power gated
MPHY CORE LANE 14               	State: Not power gated
MPHY CORE LANE 15               	State: Not power gated

Also dmesg of one of suspend attempts is attached.

Is there any prerequirement to get this patches working? Like disabling or enabling something in BIOS? Or maybe some .config option? (I used Ubuntu's default .config for 5.0rc4.)
Comment 36 Rajneesh Bhardwaj 2019-02-04 03:46:40 UTC
Looks like something is connected to USB 3 port and Wifi is also not power gated.

Just to revisit this issue again, initial problem was TBT IP was not power gated i.e. Lanes 4-7 that were fixed with a later kernel release. Then Camera IP was blocking, so if Camera Fw is loaded properly and above mentioned https://patchwork.kernel.org/patch/10714257/ patch, Camera PCI devices should be runtime suspended i.e. PCI devices 00:05.0 and 00:14.4 should show camera devices are runtime suspended.

Are we good till this state i.e. previous state on this machine?

Henceforth, the remaining blocker was XTAL clock which should be fixed with my XTAL Quirk patch from the PMC Core driver series.

I had tested this with 4.20 rc6+ , and i think with 5.0-rc1 kernel also and S0ix worked fine for me. I was accessing the device remotely and i dont think any special setting was made but you may experiment with some settings. Unfortunately, i dont have the device with me anymore and it can take a while before i get access to it again so you may please try with the attached kernel config that worked for me.
Comment 37 Rajneesh Bhardwaj 2019-02-04 03:47:44 UTC
Created attachment 280937 [details]
working config files
Comment 38 Rajneesh Bhardwaj 2019-02-04 03:48:08 UTC
Created attachment 280939 [details]
working config files
Comment 39 RussianNeuroMancer 2019-02-04 13:40:02 UTC
Sorry for noise, issue described in previous comment happened because I totally forgot that I had to disable tlp to get MPHY lanes power gated. I also remembered that there is no Linux driver for fingerprint reader (USB device) so it's probably good idea to disable it too. After disabling tlp and fingerprint sensor all MPHY lanes is power gated: 

~# cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status
MPHY CORE LANE 0                	State: Power gated
MPHY CORE LANE 1                	State: Power gated
MPHY CORE LANE 2                	State: Power gated
MPHY CORE LANE 3                	State: Power gated
MPHY CORE LANE 4                	State: Power gated
MPHY CORE LANE 5                	State: Power gated
MPHY CORE LANE 6                	State: Power gated
MPHY CORE LANE 7                	State: Power gated
MPHY CORE LANE 8                	State: Power gated
MPHY CORE LANE 9                	State: Power gated
MPHY CORE LANE 10               	State: Power gated
MPHY CORE LANE 11               	State: Power gated
MPHY CORE LANE 12               	State: Power gated
MPHY CORE LANE 13               	State: Power gated
MPHY CORE LANE 14               	State: Power gated
MPHY CORE LANE 15               	State: Power gated

(Since your patches is heading to upstream now I guess I have to fill bugreport to tlp project regarding this tlp issue.)

After disabling tlp, even without "powertop --auto-tune":

~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
46523443
~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
46420981
~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
44471300

So some S0ix state has been reached, but I not sure if S0i3 was reached because right now power consumption in suspend is still much higher than with preinstalled OS:
Windows: see Comment 14
Linux 5.0-rc4 with patches from Comment 33: 3% per one and half hours. Result is the same with and without "powertop --auto-tune". Statistics of this two tests is below, three hours of suspend in total:

~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
1066365868
~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
139486638
~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
133628200

I checked pll_status:

~# cat /sys/kernel/debug/pmc_core/pll_status
MIPI PLL                        	State: Idle
GEN2 USB2PCIE2 PLL              	State: Active
DMIPCIE3 PLL                    	State: Idle
SATA PLL                        	State: Idle

Since GEN2 USB2PCIE2 PLL is Active, I tried to disable two remaining USB devices (WiFI and LTE) and boot tablet without USB keyboard. Unfortunately, even when there is no USB devices left, GEN2 USB2PCIE2 PLL remain Active:

~# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

~# cat /sys/kernel/debug/pmc_core/pll_status
MIPI PLL                        	State: Idle
GEN2 USB2PCIE2 PLL              	State: Active
DMIPCIE3 PLL                    	State: Idle
SATA PLL                        	State: Idle

Please let me know, if I should close this bugreport now, or wait until your patches will get merged to upstream.
Should I register separate bugreport about power consumption in S0ix suspend or we can continue discuss this here and keep bugreport open until comparable power saving will be reached? 

I also tried same kernel with disabled tlp on HP EliteBook Folio G1 from Bug 201587, no success here (I didn't forget to run powertop --auto-tune to allow SATA link power management) and even more - I can't get access to debug data:

# cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status
Access denied: please disable PMC_READ_DISABLE setting in BIOS.

~# cat /sys/kernel/debug/pmc_core/pll_status
Access denied: please disable PMC_READ_DISABLE setting in BIOS.

Maybe I missing something here but seems like there is no checkbox in BIOS that can change "PMC_READ_DISABLE" state.  If possible, could you please ask your contacts in HP about this Access denied PMC_READ_DISABLE error?
Comment 40 Rajneesh Bhardwaj 2019-02-05 02:36:41 UTC
(In reply to RussianNeuroMancer from comment #39)
> Sorry for noise, issue described in previous comment happened because I
> totally forgot that I had to disable tlp to get MPHY lanes power gated. I
> also remembered that there is no Linux driver for fingerprint reader (USB
> device) so it's probably good idea to disable it too. After disabling tlp
> and fingerprint sensor all MPHY lanes is power gated: 
> 
> ~# cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status
> MPHY CORE LANE 0                      State: Power gated
> MPHY CORE LANE 1                      State: Power gated
> MPHY CORE LANE 2                      State: Power gated
> MPHY CORE LANE 3                      State: Power gated
> MPHY CORE LANE 4                      State: Power gated
> MPHY CORE LANE 5                      State: Power gated
> MPHY CORE LANE 6                      State: Power gated
> MPHY CORE LANE 7                      State: Power gated
> MPHY CORE LANE 8                      State: Power gated
> MPHY CORE LANE 9                      State: Power gated
> MPHY CORE LANE 10                     State: Power gated
> MPHY CORE LANE 11                     State: Power gated
> MPHY CORE LANE 12                     State: Power gated
> MPHY CORE LANE 13                     State: Power gated
> MPHY CORE LANE 14                     State: Power gated
> MPHY CORE LANE 15                     State: Power gated
> 
> (Since your patches is heading to upstream now I guess I have to fill
> bugreport to tlp project regarding this tlp issue.)

good idea, you may copy me there.

> 
> After disabling tlp, even without "powertop --auto-tune":
> 
> ~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
> 46523443
> ~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
> 46420981
> ~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
> 44471300
> 
> So some S0ix state has been reached, 

Its great to know that S0ix worked for you finally, after a long and patient wait.

but I not sure if S0i3 was reached
> because right now power consumption in suspend is still much higher than
> with preinstalled OS:
> Windows: see Comment 14
> Linux 5.0-rc4 with patches from Comment 33: 3% per one and half hours.
> Result is the same with and without "powertop --auto-tune". Statistics of
> this two tests is below, three hours of suspend in total:

S0ix is a platform state. SoC has reached S0ix state but there may be some platform components that are outside of SoC which may be sub optimized, not sure if finderprint reader is leaking power. Have you tried enabling low power mode in BIOS, sometimes it signals EC to reduce power but its not a universal implementation. We should check with HP on this.

> 
> ~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us
> 1066365868
> ~# cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us
> 139486638
> ~# cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec
> 133628200
> 
> I checked pll_status:
> 
> ~# cat /sys/kernel/debug/pmc_core/pll_status
> MIPI PLL                              State: Idle
> GEN2 USB2PCIE2 PLL                    State: Active
> DMIPCIE3 PLL                          State: Idle
> SATA PLL                              State: Idle
> 
> Since GEN2 USB2PCIE2 PLL is Active, I tried to disable two remaining USB
> devices (WiFI and LTE) and boot tablet without USB keyboard. Unfortunately,
> even when there is no USB devices left, GEN2 USB2PCIE2 PLL remain Active:
> 

you can ignore this one.

> ~# lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> ~# cat /sys/kernel/debug/pmc_core/pll_status
> MIPI PLL                              State: Idle
> GEN2 USB2PCIE2 PLL                    State: Active
> DMIPCIE3 PLL                          State: Idle
> SATA PLL                              State: Idle
> 
> Please let me know, if I should close this bugreport now, or wait until your
> patches will get merged to upstream.

I'd appreciate your Reviewd-and-tested-by: there. :)

> Should I register separate bugreport about power consumption in S0ix suspend
> or we can continue discuss this here and keep bugreport open until
> comparable power saving will be reached? 

I think yes, please open a new one just about high power and linking with this one for the clean recipe. We might have to work more with HP i presume since its platform related issue next but we will also try to provide best possible help we can.

> 
> I also tried same kernel with disabled tlp on HP EliteBook Folio G1 from Bug
> 201587, no success here (I didn't forget to run powertop --auto-tune to
> allow SATA link power management) and even more - I can't get access to
> debug data:
> 
> # cat /sys/kernel/debug/pmc_core/mphy_core_lanes_power_gating_status
> Access denied: please disable PMC_READ_DISABLE setting in BIOS.
> 
> ~# cat /sys/kernel/debug/pmc_core/pll_status
> Access denied: please disable PMC_READ_DISABLE setting in BIOS.
> 
> Maybe I missing something here but seems like there is no checkbox in BIOS
> that can change "PMC_READ_DISABLE" state.  If possible, could you please ask
> your contacts in HP about this Access denied PMC_READ_DISABLE error?

Yes, there is a bit that needs to be unlocked in BIOS, so HP will be able to help.

Thanks for helping on this, i really appreciate your persistence and support.
Comment 41 RussianNeuroMancer 2019-02-06 10:52:57 UTC
Upon investigation regarding tlp bugreprot I find that disabled (by default) autosuspend for USB touchpad does not prevent power gating of MPHY Lane 2. However, disabled (again, by default) autosuspend for USB Snapdragon(TM) X12 LTE-A [Qualcomm] is what prevent power gating of MPHY Lane 2. I assume autosuspend probably disabled for all 3G/4G modems, so unless distributions will start to ship service that run "powertop --auto-tune" on every boot, lack of autosuspend for modems could increase power consumption in suspend freeze for affected devices (tablets and laptops with modems).

So I wonder if there is discussion or bugreport about whitelisting modems for autosuspend, or maybe blacklisting modems that doesn't play well with autosuspend? 

> Its great to know that S0ix worked for you finally, after a long and patient
> wait.

> Thanks for helping on this, i really appreciate your persistence and support.

Thank to you again :)

> I'd appreciate your Reviewd-and-tested-by: there. :)

I didn't really reviewed this patches as am not developer, but you can add me to "Tested-by".

> good idea, you may copy me there.

You can subscribe or comment regarding tlp here: https://github.com/linrunner/TLP/issues/386

> Have you tried enabling low power mode in BIOS, sometimes it signals EC to
> reduce power but its not a universal implementation.

Answer is here: https://bugzilla.kernel.org/show_bug.cgi?id=202519#c2

> I think yes, please open a new one just about high power and linking with
> this one for the clean recipe. We might have to work more with HP i presume
> since its platform related issue next but we will also try to provide best
> possible help we can.

New bugreport is here: https://bugzilla.kernel.org/show_bug.cgi?id=202519

> Yes, there is a bit that needs to be unlocked in BIOS, so HP will be able to
> help.

This time I was able to register case at https://mycrm.support.hp.com 
Hopefully they will come up with some solution.
Comment 42 RussianNeuroMancer 2019-02-08 07:30:12 UTC
> Yes, there is a bit that needs to be unlocked in BIOS, so HP will be able to
> help.

Answer from HP was "there is no BIOS update with disabled PMC_READ_DISABLE" (at least this is what our local HP support said) and no answer at all if this request will be taken into account in future BIOS update, or they will keep PMC_READ_DISABLE flag enabled indefinitely.

Perhaps you could ask them from your side too?
Comment 43 Rajneesh Bhardwaj 2019-02-08 10:36:51 UTC
Ok. Let me try.

On 08-Feb-19 1:00 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=201579
>
> --- Comment #42 from RussianNeuroMancer (russianneuromancer@ya.ru) ---
>> Yes, there is a bit that needs to be unlocked in BIOS, so HP will be able to
>> help.
> Answer from HP was "there is no BIOS update with disabled PMC_READ_DISABLE"
> (at
> least this is what our local HP support said) and no answer at all if this
> request will be taken into account in future BIOS update, or they will keep
> PMC_READ_DISABLE flag enabled indefinitely.
>
> Perhaps you could ask them from your side too?
>
Comment 44 Ida Wallace 2019-02-20 12:22:35 UTC
Power management is administers the system-wide power policy. So thanks a lot for sharing here valuable information regarding Power Management in which details of HP Elite. 

Regards,
UK based assignment writer who serve http://www.qualityassignment.co.uk/finance-assignment-help/ at Quality Assignment which is leading academic assistance provider consultancy in UK.
Comment 45 petterson 2019-10-01 06:30:31 UTC
You completed certain reliable points there. I did a search on the subject and found nearly all persons will agree with your blog
https://www.theacademicpapers.co.uk/dissertation-writing-services-uk.php

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