kernel/linux.git/drivers/thermal/intel/Kconfig, branch v6.3

thermal: intel: BXT_PMIC: select REGMAP instead of depending on it

2023-03-01T18:32:00+00:00

REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: b474303ffd57 ("thermal: add Intel BXT WhiskeyCove PMIC thermal driver") Signed-off-by: Randy Dunlap Signed-off-by: Rafael J. Wysocki

thermal: intel: powerclamp: Use powercap idle-inject feature

2023-02-03T13:48:34+00:00

There are two idle injection implementation in the Linux kernel. One via intel_powerclamp and the other using powercap/idle_inject. Both implementation end up in calling play_idle* function from a FIFO priority thread. Both can't be used at the same time. It is better to use one idle injection framework for better maintainability. In this way, there is only one caller for play_idle. Here powercap/idle_inject can be used for both per-core and for system wide idle injection. This framework has a well defined interface which allow registry for per-core or for all CPUs (system wide). This reduces code complexity in the intel powerclamp driver as all the per CPU kthreads, delayed work and calls to play_idle can be removed. The changes include: - Remove unneeded include files - Remove per CPU kthread workers: balancing_work and idle_injection_work. - Reuse the compensation related code by moving from previous worker thread to idle_injection callback. - Adjust the idle_duration and runtime by using powercap/idle_inject interface. - Remove all variables, which are not required once powercap/idle_inject is used. - Add mutex to avoid race during removal of idle injection during module unload and user action to change idle inject percent. Also for protection during dynamic adjustment of run and idle time from update() callback. - Remove online/offline callbacks to designate control CPU - Use cpu_present_mask global variable for CPU mask - Remove hot plug locks Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki

thermal: intel: intel_pch: Use generic trip points

2023-01-24T20:13:42+00:00

The thermal framework gives the possibility to register the trip points along with the thermal zone. When that is done, no get_trip_* callbacks are needed and they can be removed. Convert the existing callbacks content logic into generic trip points initialization code and register them along with the thermal zone. In order to consolidate the code, use an ACPI trip library function to populate a generic trip point. Signed-off-by: Daniel Lezcano Reviewed-by: Zhang Rui [ rjw: Subject and changelog edits, rebase ] Signed-off-by: Rafael J. Wysocki Tested-by: Srinivas Pandruvada

thermal/x86_pkg_temp_thermal: Use Intel TCC library

2022-12-30T18:57:38+00:00

Cleanup the code by using Intel TCC library for TCC (Thermal Control Circuitry) MSR access. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal/intel/intel_tcc_cooling: Use Intel TCC library

2022-12-30T18:57:38+00:00

Cleanup the code by using Intel TCC library for TCC (Thermal Control Circuitry) MSR access. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal/intel/intel_soc_dts_iosf: Use Intel TCC library

2022-12-30T18:57:38+00:00

Cleanup the code by using Intel TCC library for TCC (Thermal Control Circuitry) MSR access. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal/intel: Introduce Intel TCC library

2022-12-30T18:57:38+00:00

There are several different drivers that accesses the Intel TCC (thermal control circuitry) MSRs, and each of them has its own implementation for the same functionalities, e.g. getting the current temperature, getting the tj_max, and getting/setting the tj_max offset. Introduce a library to unify the code for Intel CPU TCC MSR access. At the same time, ensure the temperature is got based on the updated tjmax value because tjmax can be changed at runtime for cases like the Intel SST-PP (Intel Speed Select Technology - Performance Profile) level change. Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: INTEL_HFI_THERMAL depends on NET

2022-02-10T19:58:24+00:00

THERMAL_NETLINK depends on NET and since 'select' does not follow any dependency chain, INTEL_HFI_THERMAL also should depend on NET. Fix one Kconfig warning and 48 subsequent build errors: WARNING: unmet direct dependencies detected for THERMAL_NETLINK Depends on [n]: THERMAL [=y] && NET [=n] Selected by [y]: - INTEL_HFI_THERMAL [=y] && THERMAL [=y] && (X86 [=y] || X86_INTEL_QUARK [=n] || COMPILE_TEST [=y]) && CPU_SUP_INTEL [=y] && X86_THERMAL_VECTOR [=y] Fixes: bd30cdfd9bd7 ("thermal: intel: hfi: Notify user space for HFI events") Signed-off-by: Randy Dunlap Reviewed-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Notify user space for HFI events

2022-02-03T18:50:49+00:00

When the hardware issues an HFI event, relay a notification to user space. This allows user space to respond by reading performance and efficiency of each CPU and take appropriate action. For example, when the performance and efficiency of a CPU is 0, user space can either offline the CPU or inject idle. Also, if user space notices a downward trend in performance, it may proactively adjust power limits to avoid future situations in which performance drops to 0. To avoid excessive notifications, the rate is limited by one HZ per event. To limit the netlink message size, send parameters for up to 16 CPUs in a single message. If there are more than 16 CPUs, issue as many messages as needed to notify the status of all CPUs. In the HFI specification, both performance and efficiency capabilities are defined in the [0, 255] range. The existing implementations of HFI hardware do not scale the maximum values to 255. Since userspace cares about capability values that are either 0 or show a downward/upward trend, this fact does not matter much. Relative changes in capabilities are enough. To comply with the thermal netlink ABI, scale both performance and efficiency capabilities to the [0, 1023] interval. Reviewed-by: Len Brown Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki

thermal: intel: hfi: Minimally initialize the Hardware Feedback Interface

2022-02-03T18:50:49+00:00

The Intel Hardware Feedback Interface provides guidance to the operating system about the performance and energy efficiency capabilities of each CPU in the system. Capabilities are numbers between 0 and 255 where a higher number represents a higher capability. For each CPU, energy efficiency and performance are reported as separate capabilities. Hardware computes these capabilities based on the operating conditions of the system such as power and thermal limits. These capabilities are shared with the operating system in a table resident in memory. Each package in the system has its own HFI instance. Every logical CPU in the package is represented in the table. More than one logical CPUs may be represented in a single table entry. When the hardware updates the table, it generates a package-level thermal interrupt. The size and format of the HFI table depend on the supported features and can only be determined at runtime. To minimally initialize the HFI, parse its features and allocate one instance per package of a data structure with the necessary parameters to read and navigate a local copy (i.e., owned by the driver) of individual HFI tables. A subsequent changeset will provide per-CPU initialization and interrupt handling. Reviewed-by: Len Brown Co-developed by: Aubrey Li Signed-off-by: Aubrey Li Signed-off-by: Ricardo Neri Signed-off-by: Rafael J. Wysocki