platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[verazimmerman1987]

Hi,

On a Dell XPS 14 (2026, Panther Lake, Core Ultra X7 358H) two platform
profile handlers are registered, and their choices have no common
low-power option, so the legacy /sys/firmware/acpi/platform_profile
interface exposes only "balanced performance". As a result
power-profiles-daemon cannot select a low-power firmware mode in
power-saver.

Handlers:

  platform-profile-0  name: SoC Power Slider
                      choices: low-power balanced performance
  platform-profile-1  name: dell-pc
                      choices: cool quiet balanced performance

  /sys/firmware/acpi/platform_profile_choices: balanced performance

Effect: power-saver in power-profiles-daemon leaves both handlers at
"balanced". The Dell firmware stays in its "optimized" mode, so
thermald --adaptive keeps applying the optimized DTT table (PL1
19-25 W) instead of the quiet/cool tables (PL1 15-19 W, lower skin
temperature targets). Setting the handlers individually
(dell-pc=quiet, SoC slider=low-power) works and thermald picks the
"quiet" target, but the legacy file then reports "custom" and
power-profiles-daemon falls back to "balanced", so there is no
consistent way to use it.

This looks like the same class of problem as amd-pmf + asus-wmi,
which was solved by adding "quiet" as a hidden choice in amd-pmf
(commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
for the Intel SoC Power Slider, mapped to its low-power setting, be
acceptable? I'm happy to test patches.

System:
  Kernel: 7.2.9-arch1-1
  DMI: Dell Inc. XPS 14 DA14260, BIOS 1.11.0
  power-profiles-daemon: 0.30-1
  thermald: 2:2.5.13-1

Thanks,
Vera

Re: platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[Lyndon Sanche]

Hello, thank you for reporting this.

To me there are a number of ways we could handle this.

On Fri Oct 16, 2026 at 1:10 PM EDT, verazimmerman1987 wrote:
> This looks like the same class of problem as amd-pmf + asus-wmi,
> which was solved by adding "quiet" as a hidden choice in amd-pmf
> (commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
> choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
> for the Intel SoC Power Slider, mapped to its low-power setting, be
> acceptable? I'm happy to test patches.

This certainly would fix the immediate issue: platform_profile providing
consistent choices across handlers to allow selecting a range of
profiles exposed by the system. I feel like there is a better way to
handle this besides adding hidden profiles.

What if platform_profile itself was changed to separate the user/system
choice: the "desired" profile, from the "actual" profile(s)? In this
scenario, different drivers expose different possible profiles, the
system tries to apply the closest possible profile per-driver to the
user's choice. The possible profiles would have an index to indicate
where on a linear scale it lays. If I request quiet (2), but the Intel
SoC slider only implements power-saver (3), the system chooses 3 for
that driver.

I am only thinking out loud and would find comments on this to be
useful. I realize the behaviour of some profiles do not exactly fall on
a linear scale so this would need consideration as well.

Thanks,

Lyndon

Re: platform_profile: power-saver lost on Panther Lake when SoC Power Slider and dell-pc are both bound (low-power vs quiet)

[verazimmerman1987]

Hi Lyndon,

Thanks for looking at this.

> What if platform_profile itself was changed to separate the user/system
> choice: the "desired" profile, from the "actual" profile(s)?

From the user side this sounds right, and it matches what I would
expect as a user: I pick one profile, each driver does the closest
thing it can. A few observations from testing on this machine:

1. The legacy /sys/firmware/acpi/platform_profile is where it actually
   breaks today. When I set dell-pc=quiet and the SoC slider=low-power
   by hand, the legacy file reports "custom", and power-profiles-daemon
   treats that as an external change and falls back to "balanced". If
   the legacy file reported the desired profile instead of "custom",
   the main userspace consumer would keep working.

2. On the ordering: low-power / quiet / balanced / performance fit a
   linear scale well. "cool" is less clear. On this Dell its DTT table
   has the same PL1 range as quiet (15-19 W) but a lower skin
   temperature target (40 vs 42 C), so it is more of a thermal
   preference than a power level. Placing it next to quiet, or letting
   drivers declare it as an alias of the nearest level, would probably
   be good enough.

3. Ties and gaps: when a driver has no exact match, rounding towards
   the lower-power side seems the safer default (e.g. desired quiet ->
   low-power on the SoC slider rather than balanced).

As an interim step, the hidden-choice approach would fix power-saver
on current Panther Lake Dell systems with a small, backportable
change. Another user on the same model (XPS 14 DA14260) hit the same
power-saver -> balanced fallback independently:
https://github.com/omacom/omarchy/issues/14174

I'm happy to test either approach on this hardware.

Thanks,
Vera

-------- Original Message --------
On Monday, 10/19/26 at 15:21 Lyndon Sanche <lsanche@lyndeno.ca> wrote:
Hello, thank you for reporting this.

To me there are a number of ways we could handle this.

On Fri Oct 16, 2026 at 1:10 PM EDT, verazimmerman1987 wrote:
> This looks like the same class of problem as amd-pmf + asus-wmi,
> which was solved by adding "quiet" as a hidden choice in amd-pmf
> (commit 44e94fece517, "platform/x86/amd: pmf: Add 'quiet' to hidden
> choices"). Would a similar hidden "quiet" (and perhaps "cool") choice
> for the Intel SoC Power Slider, mapped to its low-power setting, be
> acceptable? I'm happy to test patches.

This certainly would fix the immediate issue: platform_profile providing
consistent choices across handlers to allow selecting a range of
profiles exposed by the system. I feel like there is a better way to
handle this besides adding hidden profiles.

What if platform_profile itself was changed to separate the user/system
choice: the "desired" profile, from the "actual" profile(s)? In this
scenario, different drivers expose different possible profiles, the
system tries to apply the closest possible profile per-driver to the
user's choice. The possible profiles would have an index to indicate
where on a linear scale it lays. If I request quiet (2), but the Intel
SoC slider only implements power-saver (3), the system chooses 3 for
that driver.

I am only thinking out loud and would find comments on this to be
useful. I realize the behaviour of some profiles do not exactly fall on
a linear scale so this would need consideration as well.

Thanks,

Lyndon