Ignore i915/xe i2c on Modern Standby platforms

[msizanoen1]

Fixes #429

Testing:

# echo 1 > /sys/module/intel_pmc_core/parameters/warn_on_s0ix_failures
# ddcutil detect
# systemctl suspend
# dmesg | grep "CPU did not enter SLP_S0"

[rockowitz]

I can see the argument that ddcutil/libddcutil should not perform I2C operations if it detects that the system is in an idle state, but I find it hard to imagine how having executed ddcutil some time in the past should prevent entry to s0ix.

My Lenovo P16 laptop has an Alder Lake processor (12th gen), and it uses the built in graphics processor (i915 driver).

Cold booted into Mate on debian bookwom. ddcutil/llibddcutil are not installed on either /usr/bin or /usr/local/bin. Ran the following tests, which emits the "CPU did not enter" message in both the scenario you describe and also after putting the system to sleep by writing to /sys/power/state. So there's something else going on here.

root@p16:/sys/module/intel_pmc_core/parameters# cat warn_on_s0ix_failures 
N
root@p16:/sys/module/intel_pmc_core/parameters# echo 1 > warn_on_s0ix_failures 
root@p16:/sys/module/intel_pmc_core/parameters# cat warn_on_s0ix_failures 
Y
root@p16:/sys/module/intel_pmc_core/parameters# dmesg | grep "CPU did not"
root@p16:/sys/module/intel_pmc_core/parameters# systemctl suspend
<system goes to idle, awakened by keyboard>
root@p16:/sys/module/intel_pmc_core/parameters# dmesg | grep "CPU did not"
[  915.178525] intel_pmc_core INT33A1:00: CPU did not enter SLP_S0!!! (S0ix cnt=0)
root@p16:/sys/module/intel_pmc_core/parameters# 
root@p16:/sys/module/intel_pmc_core/parameters# vi /tank/temp/x1.tmp
root@p16:/sys/module/intel_pmc_core/parameters# cd /sys/power
root@p16:/sys/power# cat mem_sleep 
[s2idle] deep
root@p16:/sys/power# echo mem > state
<system goes to idle, awakened by keyboard> 
root@p16:/sys/power# 
root@p16:/sys/power# dmesg | grep "CPU did not"
[  915.178525] intel_pmc_core INT33A1:00: CPU did not enter SLP_S0!!! (S0ix cnt=0)
[ 1229.360778] intel_pmc_core INT33A1:00: CPU did not enter SLP_S0!!! (S0ix cnt=0)

[msizanoen1]

I have two different machines that all have the same symptom of sleep working on Fedora GNOME, but not on Fedora KDE (all other software components being the same, except GNOME doesn't use ddcutil). You should perform the testing steps on machines that are known to have functional s0ix under GNOME first.

(As for s0ix not working under your P16, this is usually caused by PCI devices without a driver attached, at least on Intel platforms. You can check for such devices with lspci -v.)

[rockowitz]

Between this issue and #429, there are multiple descriptions of the problem: it affects nvidia as well as i915, it requires explicit invocation of command line ddcutil vs it happens whenever it is installed. Until I understand the problem better I'm not making any changes. In particular, your patch disables ddcutil on any i915 system for which the the mem_sleep setting is s2idle, whether or not the user makes any use of modern sleep.

I will continue to explore the issue, but for now, I suggest you try putting one of the following options in $HOME/.config/ddcutil/ddcutilrc:

• disable-watch-displays: disables the background threads
• disable-api: libddcutil loads and performs basic initialization (e.g. read ddcutilrc), but performs no I²C operations. API calls to libddcutil fail, so libddcutil never performs I²C operations.

[rockowitz]

I neglected to add that as an alternative you could set environment variable POWERDEVIL_NO_DDCUTIL to disable powerdevil's use of libddcutil.

Let me know which of these alternatives, if any, resolves your problem.

[dsg22]

I have a machine affected by this issue. I worked around it by setting POWERDEVIL_NO_DDCUTIL in the unit override for plasma-powerdevil.service.

It looks like the ddcutil version I have does not have options disable-watch-displays or disable-api (v2.1.2 from fc41). Is there anything else I could test to help?