debcrafters-packages team mailing list archive

[Mario Limonciello <2115041@xxxxxxxxxxxxxxxxxx>]

If you don't mind, I'll step in and add some more context since I worked
on both the feature in 6.14 upstream kernel and the PPD change that
supports it.

In earlier kernel versions (such as 6.8 as that's mentioned above) there
can only be one vendor driver that binds to ACPI platform profile.
However, for some OEM's systems there are multiple drivers that can
bind. This situation means a race condition occurs - whichever driver
gets there first binds to the ACPI platform profile.

Depending upon what the driver does we can end up with a case that the
value reported by the kernel doesn't change everything it should and
thus the value reported by the kernel and consumed by PPD and GNOME for
the power slider position reported is not accurate.

To accommodate this behavior the ACPI platform profile core code has
been changed to a class interface that drivers register into.  Multiple
drivers can register into this class interface.  However this has a side
effect that two drivers can claim different positions.

For example; if the amd-pmf driver is in power-saver but the dell-pc
driver is in performance than what do you advertise for
/sys/firmware/acpi/platform_profile?  This is why a new string 'custom'
was introduced.  It makes it clear this is an undefined position.

PPD had to be modified to account for this new string.  If PPD isn't
modified then the system will be in an undefined power state.

The Dell systems that prompted this SRU have a BIOS option that
configures the user selectable thermal tables which are read by the
dell-pc driver.  Depending upon what the setting is configured as it's
possible to boot up with the two drivers having different values and
then the power slider being in an undefined position.


FTR - I am not at all worried about risk with this SRU.  It is supporting a new string that only exists in 6.14 or later.

-- 
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to power-profiles-daemon in
Ubuntu.
https://bugs.launchpad.net/bugs/2115041

Title:
  Can't recognize custom ACPI platform profile

Status in OEM Priority Project:
  New
Status in power-profiles-daemon package in Ubuntu:
  In Progress

Bug description:
  [ Impact ]

   * The thermal management policy may impacts cooling device operation
  like fan, for example, it can keep the fan speed high when user select
  performance in case a throttling happened. Without the change, it
  won't change the fan mode, so that the fan speed might be limited for
  not being so noisy, however, the real outcome depends on the platform
  design (some platforms may not have fan). In conclusion, the new AMD
  platform is less likely being throttled with the change.

  The mapping relationship power mode and platform profiles:
  performance <-> performance
  balanced <-> balanced/balanced_performance/cool
  power saver <-> low-power/quiet

  [ Test Plan ]

   * On AMD Strix Point/Krackan Point platform which has sysfs node
  /sys/firmware/acpi/platform_profile

   * Try to modify power mode by $ sudo powerprofilectl set <power-mode>

   * Check if /sys/firmware/acpi/platform_profile being updated

   * After reboot, check if BIOS update the ThermalManagement setting by
  $ fwupdmgr get-bios-setting ThermalManagement

  [ Where problems could occur ]

   * The platform will list supported platform_profile in
  /sys/firmware/acpi/platform_profile_choices, the DPP power mode should
  map to one of it, otherwise, it can't select the correct thermal
  policy. If the platform set the unexpected string which the mapping is
  not defined in the PPD. The thermal policy can't be switched
  successfully.

  [ Other Info ]

   * Upstream commit: https://gitlab.freedesktop.org/upower/power-
  profiles-daemon/-/commit/6b565b0b05a2bc92e3c546a567b394f415937265

   * The patch is in 25.04 and 25.10 already.

   * To the kernel without platform_profile node [1], the user
  experience is just as before.

  [1] https://docs.kernel.org/userspace-api/sysfs-platform_profile.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/2115041/+subscriptions