Firmware-based thermal temperature control loops may aggressively
throttle performance to prevent temperature overshoots relative to the
defined target temperature. This can negatively impact performance. User
space may prefer to prioritize performance, even if it results in
temperature overshoots with in acceptable range.
For example, user space might tolerate temperature overshoots when the
device is placed on a desk, as opposed to when it's on a lap. To
accommodate such scenarios, an optional attribute is provided to specify
a tolerance level for temperature overshoots while maintaining acceptable
performance.
Attribute:
thermal_tolerance: This attribute ranges from 0 to 7, where 0 represents
the most aggressive control to avoid any temperature overshoots, and 7
represents a more graceful approach, favoring performance even at the
expense of temperature overshoots.
Note: This level may not scale linearly. For example, a value of 3 does not
necessarily imply a 50% improvement in performance compared to a value of 0.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20250613214923.2910397-1-srinivas.pandruvada@linux.intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
When the hardware reduces the power to the minimum possible, the power
floor is notified via an interrupt.
This can happen when user space requests a power limit via powercap RAPL
interface, which forces the system to enter to the lowest power. This
power floor indication can be used as a hint to resort to other methods
of reducing power than via RAPL power limit.
Before power floor status can be read or the firmware can trigger
notifications regarding it, it needs to be configured via a mailbox
command. The actual power floor status is read via bit 39 of MMIO
offset 0x5B18 of the processor thermal PCI device.
To show the current power floor status and get notification
on a sysfs attribute, add 2 new attributes to
/sys/bus/pci/devices/0000\:00\:04.0/power_limits/
power_floor_enable : This attribute is present when power floor
notifications are supported. This attribute allows to enable/disable
power floor notifications.
power_floor_status : This attribute is present when power floor
notifications are supported. When enabled via power_floor_enable, this
attribute shows the current power floor status.
The power floor implementation provides interfaces which are called
from the sysfs callbacks to enable/disable and read power floor
status. It also provides two additional interfaces to check if the
current processor thermal device interrupt is for power floor status
and to send notifications to user space.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Changelog and documentation changes edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Prior to Meteor Lake processor generation, user space can pass workload
type request to the firmware. Then firmware can optimize power based on
the indicated workload type. User space also uses workload type requests
to implement its own heuristics.
The firmware in Meteor Lake processor generation is capable of predicting
workload type without software help.
To avoid duplicate processing, add a sysfs interface allowing user space
to obtain the workload hint from the firmware instead of trying to
predict the workload type by itself.
This workload hint is passed from the firmware via MMIO offset 0x5B18 of
the processor thermal PCI device. Before workload hints can be produced by
the firmware, it needs to be configured via a mailbox command. This
mailbox command turns ON the workload hint and it allows to program a
notification delay to control the rate of notifications.
The notification delay can be changed from user space vis sysfs.
Attribute group 'workload_hint' in sysfs is used for implementing the
workload hints interface between user space and the kernel.
It contains the following attributes:
workload_type_enable:
Enables/disables workload type hints from the firmware.
notification_delay_ms:
Notification delay in milliseconds.
workload_type_index:
The current workload type index predicted by the firmware (see
the documentation changes below for supported index values and
their meaning).
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Changelog edits, documentation edits, whitespace adjustments ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add support for DLVR (Digital Linear Voltage Regulator) attributes,
which can be used to control RFIM.
Here instead of "fivr" another directory "dlvr" is created with DLVR
attributes:
/sys/bus/pci/devices/0000:00:04.0/dlvr
├── dlvr_freq_mhz
├── dlvr_freq_select
├── dlvr_hardware_rev
├── dlvr_pll_busy
├── dlvr_rfim_enable
└── dlvr_spread_spectrum_pct
└── dlvr_control_mode
└── dlvr_control_lock
Attributes
dlvr_freq_mhz (RO):
Current DLVR PLL frequency in MHz.
dlvr_freq_select (RW):
Sets DLVR PLL clock frequency.
dlvr_hardware_rev (RO):
DLVR hardware revision.
dlvr_pll_busy (RO):
PLL can't accept frequency change when set.
dlvr_rfim_enable (RW):
0: Disable RF frequency hopping, 1: Enable RF frequency hopping.
dlvr_control_mode (RW):
Specifies how frequencies are spread. 0: Down spread, 1: Spread in Center.
dlvr_control_lock (RW):
1: future writes are ignored.
dlvr_spread_spectrum_pct (RW)
A write to this register updates the DLVR spread spectrum percent value.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
It is possible that the system manufacturer locks down thermal tuning
beyond what is usually done on the given platform. In that case user
space calibration tools should not try to adjust the thermal
configuration of the system.
To allow user space to check if that is the case, add a new sysfs
attribute "production_mode" that will be present when the ACPI DCFG
method is present under the INT3400 device object in the ACPI Namespace.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Document Intel Dynamic Platform and Thermal Framework (DPTF)
ABI.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
