Merge tag 'thermal-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull thermal control updates from Rafael Wysocki:
 "These add Nova Lake processor support to the Intel thermal drivers and
  DPTF code, update thermal control documentation, simplify the ACPI
  DPTF code related to thermal control, add QCS8300 compatible to the
  tsens thermal DT bindings, add DT bindings for NXP i.MX91 thermal
  module and add support for it to the imx91 thermal driver, update a
  few other thermal drivers and fix a format string issue in a thermal
  utility:

   - Add Nova Lake processor thermal device to the int340x
     processor_thermal driver, add DLVR support for Nova Lake to it, add
     Nova Lake support to the ACPI DPTF code, document thermal
     throttling on Intel platforms, and update workload type hint
     interface documentation (Srinivas Pandruvada)

   - Remove int340x thermal scan handler from the ACPI DPTF code because
     it turned out to be unnecessary (Slawomir Rosek)

   - Clean up the Intel int340x thermal driver (Kaushlendra Kumar)

   - Document the RZ/V2H TSU DT bindings (Ovidiu Panait)

   - Document the Kaanapali Temperature Sensor (Manaf Meethalavalappu
     Pallikunhi)

   - Document R-Car Gen4 and RZ/G2 support in driver comment (Marek
     Vasut)

   - Convert to DEFINE_SIMPLE_DEV_PM_OPS() in R-Car [Gen3] (Geert
     Uytterhoeven)

   - Fix format string bug in thermal-engine (Malaya Kumar Rout)

   - Make ipq5018 tsens standalone compatible (George Moussalem)

   - Add the QCS8300 compatible for QCom Tsens (Gaurav Kohli)

   - Add support for the NXP i.MX91 thermal module, including the DT
     bindings (Pengfei Li)"

* tag 'thermal-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  thermal/drivers/imx91: Add support for i.MX91 thermal monitoring unit
  dt-bindings: thermal: fsl,imx91-tmu: add bindings for NXP i.MX91 thermal module
  dt-bindings: thermal: tsens: Add QCS8300 compatible
  dt-bindings: thermal: qcom-tsens: make ipq5018 tsens standalone compatible
  tools/thermal/thermal-engine: Fix format string bug in thermal-engine
  docs: driver-api/thermal/intel_dptf: Add new workload type hint
  thermal/drivers/rcar_gen3: Convert to DEFINE_SIMPLE_DEV_PM_OPS()
  thermal/drivers/rcar: Convert to DEFINE_SIMPLE_DEV_PM_OPS()
  Documentation: thermal: Document thermal throttling on Intel platforms
  ACPI: DPTF: Support Nova Lake
  thermal: intel: int340x: Add DLVR support for Nova Lake
  thermal: int340x: processor_thermal: Add Nova Lake processor thermal device
  thermal: intel: int340x: Replace sprintf() with sysfs_emit()
  thermal: intel: int340x: Use symbolic constant for UUID comparison
  thermal/drivers/rcar_gen3: Document R-Car Gen4 and RZ/G2 support in driver comment
  dt-bindings: thermal: qcom-tsens: document the Kaanapali Temperature Sensor
  dt-bindings: thermal: r9a09g047-tsu: Document RZ/V2H TSU
  ACPI: DPTF: Remove int340x thermal scan handler
  thermal: intel: Select INT340X_THERMAL from INTEL_SOC_DTS_THERMAL

2 files changed, 92 insertions, 0 deletions

diff --git a/Documentation/admin-guide/thermal/index.rst b/Documentation/admin-guide/thermal/index.rst
index 193b7b01a87d..e48bc0a1951b 100644
--- a/Documentation/admin-guide/thermal/index.rst
+++ b/Documentation/admin-guide/thermal/index.rst
@@ -6,3 +6,4 @@ Thermal Subsystem
    :maxdepth: 1
 
    intel_powerclamp
+   intel_thermal_throttle
diff --git a/Documentation/admin-guide/thermal/intel_thermal_throttle.rst b/Documentation/admin-guide/thermal/intel_thermal_throttle.rst
new file mode 100644
index 000000000000..f4fbf9d5a4ec
--- /dev/null
+++ b/Documentation/admin-guide/thermal/intel_thermal_throttle.rst
@@ -0,0 +1,91 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+=======================================
+Intel thermal throttle events reporting
+=======================================
+
+:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+Introduction
+------------
+
+Intel processors have built in automatic and adaptive thermal monitoring
+mechanisms that force the processor to reduce its power consumption in order
+to operate within predetermined temperature limits.
+
+Refer to section "THERMAL MONITORING AND PROTECTION" in the "Intel® 64 and
+IA-32 Architectures Software Developer’s Manual Volume 3 (3A, 3B, 3C, & 3D):
+System Programming Guide" for more details.
+
+In general, there are two mechanisms to control the core temperature of the
+processor. They are called "Thermal Monitor 1 (TM1) and Thermal Monitor 2 (TM2)".
+
+The status of the temperature sensor that triggers the thermal monitor (TM1/TM2)
+is indicated through the "thermal status flag" and "thermal status log flag" in
+MSR_IA32_THERM_STATUS for core level and MSR_IA32_PACKAGE_THERM_STATUS for
+package level.
+
+Thermal Status flag, bit 0 — When set, indicates that the processor core
+temperature is currently at the trip temperature of the thermal monitor and that
+the processor power consumption is being reduced via either TM1 or TM2, depending
+on which is enabled. When clear, the flag indicates that the core temperature is
+below the thermal monitor trip temperature. This flag is read only.
+
+Thermal Status Log flag, bit 1 — When set, indicates that the thermal sensor has
+tripped since the last power-up or reset or since the last time that software
+cleared this flag. This flag is a sticky bit; once set it remains set until
+cleared by software or until a power-up or reset of the processor. The default
+state is clear.
+
+It is possible that when user reads MSR_IA32_THERM_STATUS or
+MSR_IA32_PACKAGE_THERM_STATUS, TM1/TM2 is not active. In this case,
+"Thermal Status flag" will read "0" and the "Thermal Status Log flag" will be set
+to show any previous "TM1/TM2" activation. But since it needs to be cleared by
+the software, it can't show the number of occurrences of "TM1/TM2" activations.
+
+Hence, Linux provides counters of how many times the "Thermal Status flag" was
+set. Also presents how long the "Thermal Status flag" was active in milliseconds.
+Using these counters, users can check if the performance was limited because of
+thermal events. It is recommended to read from sysfs instead of directly reading
+MSRs as the "Thermal Status Log flag" is reset by the driver to implement rate
+control.
+
+Sysfs Interface
+---------------
+
+Thermal throttling events are presented for each CPU under
+"/sys/devices/system/cpu/cpuX/thermal_throttle/", where "X" is the CPU number.
+
+All these counters are read-only. They can't be reset to 0. So, they can potentially
+overflow after reaching the maximum 64 bit unsigned integer.
+
+``core_throttle_count``
+	Shows the number of times "Thermal Status flag" changed from 0 to 1 for this
+	CPU since OS boot and thermal vector is initialized. This is a 64 bit counter.
+
+``package_throttle_count``
+	Shows the number of times "Thermal Status flag" changed from 0 to 1 for the
+	package containing this CPU since OS boot and thermal vector is initialized.
+	Package status is broadcast to all CPUs; all CPUs in the package increment
+	this count. This is a 64-bit counter.
+
+``core_throttle_max_time_ms``
+	Shows the maximum amount of time for which "Thermal Status flag" has been
+	set to 1 for this CPU at the core level since OS boot and thermal vector
+	is initialized.
+
+``package_throttle_max_time_ms``
+	Shows the maximum amount of time for which "Thermal Status flag" has been
+	set to 1 for the package containing this CPU since OS boot and thermal
+	vector is initialized.
+
+``core_throttle_total_time_ms``
+	Shows the cumulative time for which "Thermal Status flag" has been
+	set to 1 for this CPU for core level since OS boot and thermal vector
+	is initialized.
+
+``package_throttle_total_time_ms``
+	Shows the cumulative time for which "Thermal Status flag" has been set
+	to 1 for the package containing this CPU since OS boot and thermal vector
+	is initialized.