The too-many-positional-arguments warning introduced in commit 4a367430
caused a regression in pylint-integration-tests for versions of pylint < 3.3.0,
as these versions do not support the too-many-positional-arguments check.
Added disable=unknown-option-value to the pylint disable line for compatibility
with pylint < 3.3.0, avoiding test failures.
Kept disable=too-many-positional-arguments for pylint >= 3.3.0, since the
function exceeds the maximum allowed positional arguments (R0917) and may cause
lint errors.
Fixes: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/174
Rather than checking for active mode at startup and then never checking
it again check the mode when trying to write a value.
If it's not active, log something to the journal. This is intentionally
not failing because users could still have an ACPI platform-profile change
occur.
Fixes: https://gitlab.freedesktop.org/upower/power-profiles-daemon/-/issues/168
From systemd.unit(5):
Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is
not a dependency), such as AssertPathExists= (or e.g. ExecStart= in service units), one needs to first
clear the list before re-adding all entries except the one that is to be removed. Dependencies (After=,
etc.) cannot be reset to an empty list, so dependencies can only be added in drop-ins. If you want to
remove dependencies, you have to override the entire unit.
https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html
PPD doesn't force the SoC to active mode or to load.
As the policy of whether amd-pstate is loaded is controlled by the
kernel having another policy whether power-profiles-daemon isn't
necessary.
We don't need to do it for each proxy since they're all monitoring
the same owner.
So basically make the first proxy to be setup to win, not connecting to
the signal if the other is already set
Due a firmware bug on some OEM systems the amd-pstate kernel driver
starts up in active mode but EPP writes don't work.
Admittedly this is a kernel bug that it still advertises support and
it could be handled better by the kernel, but PPD can also validate
writes with a no-op for each CPU at bootup.
Do this to ensure that the CPU driver is only setup if we know it works.
It's not critical for the boot process in any way, and this should
help with any race conditions form kernel modules still setting
up anything related devices after the initial device uevent.
More users use power saver as their default value than expected, and
so ABM is a more negative experience for some of them.
Instead of a table of values, use "progressive" values that change
based on battery life.
The selected values:
* Balanced + AC:
ABM 0
* Balanced + battery:
>= 30% battery
ABM 0
< 30% battery
ABM 1
* Power Saver + AC:
ABM 0
* Power Saver + battery:
>= 50% battery
ABM 0
30-49% battery
ABM 1
20-30% battery
ABM 2
<20% battery
ABM 3
Although the system will save more power at lower frequency, AMD SoCs
have a point when they can operate most efficiently called the lowest
non-linear frequency.
Program the minimum frequency to this value in balanced and performance
modes to improve responsiveness.
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Simplify our writing function by just using pure C open/write calls
since we don't really need to be able to create files.
In fact this made possible to spot a test issue where a file was not
present and in fact in some scenarios we had random valgrind errors in
CI.
Plus, since we just need to write the contents as it is, we can avoid
extra buffers.
