- 11 Mar, 2024 14 commits
-
-
Konrad Dybcio authored
Currently, thermal zones associated with providers that have interrupts for signaling hot/critical trips are required to set a polling-delay of 0 to indicate no polling. This feels a bit backwards. Change the code such that "no polling delay" also means "no polling". Suggested-by:
Bjorn Andersson <andersson@kernel.org> Signed-off-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-2-3c9d4dced138@linaro.org
-
Konrad Dybcio authored
Currently, thermal zones associated with providers that have interrupts for signaling hot/critical trips are required to set a polling-delay of 0 to indicate no polling. This feels a bit backwards. Assume 0 (no polling) when these properties are not defined. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
-
Peng Fan authored
TMU Version 1 has 4 TTRCRs, while TMU Version >=2 has 16 TTRCRs. So limit the len to 4 will report "invalid range data" for i.MX93. This patch drop the local array with allocated ttrcr array and able to support larger tmu ranges. Fixes: f12d60c8 ("thermal/drivers/qoriq: Support version 2.1") Tested-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
-
Mark Brown authored
Currently the sun8i thermal driver will fail to probe if any of the thermal zones it is registering fails to register with the thermal core. Since we currently do not define any trip points for the GPU thermal zones on at least A64 or H5 this means that we have no thermal support on these platforms: [ 1.698703] thermal_sys: Failed to find 'trips' node [ 1.698707] thermal_sys: Failed to find trip points for thermal-sensor id=1 even though the main CPU thermal zone on both SoCs is fully configured. This does not seem ideal, while we may not be able to use all the zones it seems better to have those zones which are usable be operational. Instead just carry on registering zones if we get any non-deferral error, allowing use of those zones which are usable. This means that we also need to update the interrupt handler to not attempt to notify the core for events on zones which we have not registered, I didn't see an ability to mask individual interrupts and I would expect that interrupts would still be indicated in the ISR even if they were masked. Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Martin Botka authored
Add support for the thermal sensor found in H616 SoCs, is the same as the H6 thermal sensor controller, but with four sensors. Also the registers readings are wrong, unless a bit in the first SYS_CFG register cleared, so set exercise the SRAM regmap to take care of that. Signed-off-by:
Martin Botka <martin.botka@somainline.org> Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
-
Andre Przywara authored
The Allwinner H616 SoC needs to clear a bit in one register in the SRAM controller, to report reasonable temperature values. On reset, bit 16 in register 0x3000000 is set, which leads to the driver reporting temperatures around 200C. Clearing this bit brings the values down to the expected range. The BSP code does a one-time write in U-Boot, with a comment just mentioning the effect on the THS, but offering no further explanation. To not rely on firmware to set things up for us, add code that queries the SRAM controller device via a DT phandle link, then clear just this single bit. Signed-off-by:
-
Maksim Kiselev authored
The H616 SoC resembles the H6 thermal sensor controller, with a few changes like four sensors. Extend sun50i_h6_ths_calibrate() function to support calibration of these sensors. Co-developed-by:
Maksim Kiselev <bigunclemax@gmail.com> Reviewed-by:
-
Andre Przywara authored
So far we were ORing in some "unknown" value into the THS control register on the Allwinner H6. This part of the register is not explained in the H6 manual, but the H616 manual details those bits, and on closer inspection the THS IP blocks in both SoCs seem very close: - The BSP code for both SoCs writes the same values into THS_CTRL. - The reset values of at least the first three registers are the same. Replace the "unknown" value with its proper meaning: "acquire time", most probably the sample part of the sample & hold circuit of the ADC, according to its explanation in the H616 manual. No functional change, just a macro rename and adjustment. Signed-off-by:
-
Martin Botka authored
This controller is similar to the H6, but covers four sensors and uses slightly different calibration methods. Also the H616 requires to poke a bit in the SYS_CFG register range for correct operation, so add a phandle property to point there. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
Andre Przywara authored
The Allwinner H616 SoC contains a mysterious bit at register offset 0x0 in the SRAM control block. If bit 16 is set (the reset value), the temperature readings of the THS are way off, leading to reports about 200C, at normal ambient temperatures. Clearing this bits brings the reported values down to the expected values. The BSP code clears this bit in firmware (U-Boot), and has an explicit comment about this, but offers no real explanation. Experiments in U-Boot show that register 0x0 has no effect on the SRAM C visibility: all tested bit settings still allow full read and write access by the CPU to the whole of SRAM C. Only bit 24 of the register at offset 0x4 makes all of SRAM C inaccessible by the CPU. So modelling the THS switch functionality as an SRAM region would not reflect reality. Since we should not rely on firmware settings, allow other code (the THS driver) to access this register, by exporting it through the already existing regmap. This mimics what we already do for the LDO control and the EMAC register. To avoid concurrent accesses to the same register at the same time, by the SRAM switch code and the regmap code, use the same lock to protect the access. The regmap subsystem allows to use an existing lock, so we just need to hook in there. Signed-off-by:
-
Fabio Estevam authored
The number of fsl,tmu-range entries vary among the several NXP SoCs. - lx2160a has two fsl,tmu-range entries (fsl,qoriq-tmu compatible) - imx8mq has four fsl,tmu-range entries. (fsl,imx8mq-tmu compatible) - imx93 has seven fsl,tmu-range entries. (fsl,qoriq-tmu compatible) Change minItems and maxItems accordingly. This fixes the following schema warning: imx93-11x11-evk.dtb: tmu@44482000: fsl,tmu-range: 'oneOf' conditional failed, one must be fixed: [2147483866, 2147483881, 2147483906, 2147483946, 2147484006, 2147484071, 2147484086] is too long Signed-off-by:Fabio Estevam <festevam@denx.de> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
There is never a need to have a space before a TAB, but it hurts the eyes of vim users. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Frank Wunderlich authored
Reading thermal sensor on mt7986 devices returns invalid temperature: bpi-r3 ~ # cat /sys/class/thermal/thermal_zone0/temp -274000 Fix this by adding missing members in mtk_thermal_data struct which were used in mtk_thermal_turn_on_buffer after commit 33140e66. Cc: stable@vger.kernel.org Fixes: 33140e66 ("thermal/drivers/mediatek: Control buffer enablement tweaks") Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Reviewed-by:
Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by:
Daniel Golle <daniel@makrotopia.org> Tested-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Christophe JAILLET authored
If devm_krealloc() fails, then 'efuse' is leaking. So free it to avoid a leak. Fixes: f5f633b1 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by:
-
- 07 Mar, 2024 1 commit
-
-
Rafael J. Wysocki authored
Merge thermal core changes and Intel thermal drivers changes for 6.9-rc1: - Store zone trips table and zone operations directly in struct thermal_zone_device (Rafael Wysocki). - Rework writable trip points handling (Rafael Wysocki). - Thermal core code cleanups (Dan Carpenter, Flavio Suligoi). - Use thermal zone accessor functions in the int340x Intel thermal driver (Rafael Wysocki). - Add Lunar Lake-M PCI ID to the int340x Intel thermal driver (Srinivas Pandruvada). * thermal-core: thermal: core: remove unnecessary check in trip_point_hyst_store() thermal: core: Remove excess empty line from a comment thermal: core: Eliminate writable trip points masks thermal: of: Set THERMAL_TRIP_FLAG_RW_TEMP directly thermal: imx: Set THERMAL_TRIP_FLAG_RW_TEMP directly wifi: iwlwifi: mvm: Set THERMAL_TRIP_FLAG_RW_TEMP directly mlxsw: core_thermal: Set THERMAL_TRIP_FLAG_RW_TEMP directly thermal: intel: Set THERMAL_TRIP_FLAG_RW_TEMP directly thermal: core: Drop the .set_trip_hyst() thermal zone operation thermal: core: Add flags to struct thermal_trip thermal: core: Move initial num_trips assignment before memcpy() thermal: Get rid of CONFIG_THERMAL_WRITABLE_TRIPS thermal: intel: Adjust ops handling during thermal zone registration thermal: ACPI: Constify acpi_thermal_zone_ops thermal: core: Store zone ops in struct thermal_zone_device thermal: intel: Discard trip tables after zone registration thermal: ACPI: Discard trips table after zone registration thermal: core: Store zone trips table in struct thermal_zone_device * thermal-intel: thermal: intel: int340x_thermal: Use thermal zone accessor functions thermal: int340x: processor_thermal: Add Lunar Lake-M PCI ID
-
- 06 Mar, 2024 1 commit
-
-
Dan Carpenter authored
This code was shuffled around a bit recently. We no longer need to check the value of "ret" because we know it's zero. Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 05 Mar, 2024 3 commits
-
-
Rafael J. Wysocki authored
Make int340x_thermal use the dedicated accessor functions for the thermal zone device object address and the thermal zone type string. This is requisite for future thermal core improvements. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
-
Rafael J. Wysocki authored
-
Flavio Suligoi authored
The first and the third lines of the kerneldoc comment for: thermal_zone_device_set_polling() belong to the same sentences, so join them together. Signed-off-by:
Flavio Suligoi <f.suligoi@asem.it> [ rjw: Subject and changelog edits ] Signed-off-by:
-
- 28 Feb, 2024 1 commit
-
-
Srinivas Pandruvada authored
Add Lunar Lake-M PCI ID for processor thermal device. Signed-off-by:
-
- 27 Feb, 2024 9 commits
-
-
Rafael J. Wysocki authored
All of the thermal_zone_device_register_with_trips() callers pass zero writable trip points masks to it, so drop the mask argument from that function and update all of its callers accordingly. This also removes the artificial trip points per zone limit of 32, related to using writable trip points masks. No intentional functional impact. Signed-off-by:
-
Rafael J. Wysocki authored
It is now possible to flag trip points with THERMAL_TRIP_FLAG_RW_TEMP to allow their temperature to be set from user space via sysfs instead of using a nonzero writable trips mask during thermal zone registration, so make the OF thermal code do that. No intentional functional impact. Note that this change is requisite for dropping the mask argument from thermal_zone_device_register_with_trips() going forward. Signed-off-by:
-
Rafael J. Wysocki authored
It is now possible to flag trip points with THERMAL_TRIP_FLAG_RW_TEMP to allow their temperature to be set from user space via sysfs instead of using a nonzero writable trips mask during thermal zone registration, so make the imx thermal code do that. No intentional functional impact. Note that this change is requisite for dropping the mask argument from thermal_zone_device_register_with_trips() going forward. Signed-off-by:
-
Rafael J. Wysocki authored
It is now possible to flag trip points with THERMAL_TRIP_FLAG_RW_TEMP to allow their temperature to be set from user space via sysfs instead of using a nonzero writable trips mask during thermal zone registration, so make the iwlwifi code do that. No intentional functional impact. Note that this change is requisite for dropping the mask argument from thermal_zone_device_register_with_trips() going forward. Signed-off-by:
-
Rafael J. Wysocki authored
It is now possible to flag trip points with THERMAL_TRIP_FLAG_RW_TEMP to allow their temperature to be set from user space via sysfs instead of using a nonzero writable trips mask during thermal zone registration, so make the mlxsw code do that. No intentional functional impact. Note that this change is requisite for dropping the mask argument from thermal_zone_device_register_with_trips() going forward. Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
-
Rafael J. Wysocki authored
Some Intel thermal drivers need/want the temperature of their trip points to be set by user space via sysfs and so they pass nonzero writable trip masks during thermal zone registration for this purpose. It is now possible to achieve the same result by setting the THERMAL_TRIP_FLAG_RW_TEMP trip flag directly, so modify the drivers in question to do that instead of using a nonzero writable trips mask. No intentional functional impact. Note that this change is requisite for dropping the mask argument from thermal_zone_device_register_with_trips() going forward. Signed-off-by:
-
Rafael J. Wysocki authored
None of the users of the thermal core provides a .set_trip_hyst() thermal zone operation, so drop that callback from struct thermal_zone_device_ops and update trip_point_hyst_store() accordingly. No functional impact. Signed-off-by:
-
Rafael J. Wysocki authored
In order to allow thermal zone creators to specify the writability of trip point temperature and hysteresis on a per-trip basis, add a flags field to struct thermal_trip and define flags to represent the desired trip properties. Also make thermal_zone_device_register_with_trips() set the THERMAL_TRIP_FLAG_RW_TEMP flag for all trips covered by the writable trips mask passed to it and modify the thermal sysfs code to look at the trip flags instead of using the writable trips mask directly or checking the presence of the .set_trip_hyst() zone callback. Additionally, make trip_point_temp_store() and trip_point_hyst_store() fail with an error code if the trip passed to one of them has THERMAL_TRIP_FLAG_RW_TEMP or THERMAL_TRIP_FLAG_RW_HYST, respectively, clear in its flags. No intentional functional impact. Signed-off-by: -
Nathan Chancellor authored
When booting a CONFIG_FORTIFY_SOURCE=y kernel compiled with a toolchain that supports __counted_by() (such as clang-18 and newer), there is a panic on boot: [ 2.913770] memcpy: detected buffer overflow: 72 byte write of buffer size 0 [ 2.920834] WARNING: CPU: 2 PID: 1 at lib/string_helpers.c:1027 __fortify_report+0x5c/0x74 ... [ 3.039208] Call trace: [ 3.041643] __fortify_report+0x5c/0x74 [ 3.045469] __fortify_panic+0x18/0x20 [ 3.049209] thermal_zone_device_register_with_trips+0x4c8/0x4f8 This panic occurs because trips is counted by num_trips but num_trips is assigned after the call to memcpy(), so the fortify checks think the buffer size is zero because tz was allocated with kzalloc(). Move the num_trips assignment before the memcpy() to resolve the panic and ensure that the fortify checks work properly. Fixes: 9b0a6275 ("thermal: core: Store zone trips table in struct thermal_zone_device") Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
- 23 Feb, 2024 8 commits
-
-
Rafael J. Wysocki authored
The only difference made by CONFIG_THERMAL_WRITABLE_TRIPS is whether or not the writable trips mask passed during thermal zone registration will take any effect, but whoever passes a non-zero writable trips mask to thermal_zone_device_register_with_trips() can be forgiven thinking that it will always work. Moreover, some thermal drivers expect user space to set trip temperature values, so they select CONFIG_THERMAL_WRITABLE_TRIPS, possibly overriding a manual choice to unset it and going against the design purportedly allowing system integrators to decide on the writability of trip points for the given kernel build. It is also set in one platform's defconfig. Forthermore, CONFIG_THERMAL_WRITABLE_TRIPS only affects trip temperature, because trip hysteresis is writable as long as the thermal zone provides a callback to update it, regardless of the CONFIG_THERMAL_WRITABLE_TRIPS value. The above means that the symbol in question is used inconsistently and its purpose is at least moot, so remove it and always take the writable trip mask passed to thermal_zone_device_register_with_trips() into account. Signed-off-by:
-
Rafael J. Wysocki authored
Because thermal zone operations are now stored directly in struct thermal_zone_device, thermal zone creators can discard the operations structure after the zone registration is complete, or it can be made read-only. Accordingly, make int340x_thermal_zone_add() use a local variable to represent thermal zone operations, so it is freed automatically upon the function exit, and make the other Intel thermal drivers use const zone operations structures. Signed-off-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Reviewed-by:
-
Rafael J. Wysocki authored
Because thermal zone operations are now stored directly in struct thermal_zone_device, acpi_thermal_zone_ops need not be modified by the thermal core and so it can be const. Adjust the code accordingly. No functional impact. Signed-off-by:
-
Rafael J. Wysocki authored
The current code requires thermal zone creators to pass pointers to writable ops structures to thermal_zone_device_register_with_trips() which needs to modify the target struct thermal_zone_device_ops object if the "critical" operation in it is NULL. Moreover, the callers of thermal_zone_device_register_with_trips() are required to hold on to the struct thermal_zone_device_ops object passed to it until the given thermal zone is unregistered. Both of these requirements are quite inconvenient, so modify struct thermal_zone_device to contain struct thermal_zone_device_ops as field and make thermal_zone_device_register_with_trips() copy the contents of the struct thermal_zone_device_ops passed to it via a pointer (which can be const now) to that field. Also adjust the code using thermal zone ops accordingly and modify thermal_of_zone_register() to use a local ops variable during thermal zone registration so ops do not need to be freed in thermal_of_zone_unregister() any more. Signed-off-by:
-
Rafael J. Wysocki authored
Because the thermal core creates and uses its own copy of the trips table passed to thermal_zone_device_register_with_trips(), it is not necessary to hold on to a local copy of it any more after the given thermal zone has been registered. Accordingly, modify Intel thermal drivers to discard the trips tables passed to thermal_zone_device_register_with_trips() after thermal zone registration, for example by storing them in local variables which are automatically discarded when the zone registration is complete. Also make some additional code simplifications unlocked by the above changes. Signed-off-by:
-
Rafael J. Wysocki authored
Because the thermal core creates and uses its own copy of the trips table passed to thermal_zone_device_register_with_trips(), it is not necessary to hold on to a local copy of it any more after the given thermal zone has been registered. Accordingly, modify the ACPI thermal driver to store the trips table passed to thermal_zone_device_register_with_trips() in a local variable which is automatically discarded when acpi_thermal_add() returns to its caller. Also make some additional code simplifications unlocked by the above change. Signed-off-by:
-
Rafael J. Wysocki authored
The current code expects thermal zone creators to pass a pointer to a writable trips table to thermal_zone_device_register_with_trips() and that trips table is then used by the thermal core going forward. Consequently, the callers of thermal_zone_device_register_with_trips() are required to hold on to the trips table passed to it until the given thermal zone is unregistered, at which point the trips table can be freed, but at the same time they are not expected to access that table directly. This is both error prone and confusing. To address it, turn the trips table pointer in struct thermal_zone_device into a flex array (counted by its num_trips field), allocate it during thermal zone device allocation and copy the contents of the trips table supplied by the zone creator (which can be const now) into it, which will allow the callers of thermal_zone_device_register_with_trips() to drop their trip tables right after the zone registration. This requires the imx thermal driver to be adjusted to store the new temperature in its internal trips table in imx_set_trip_temp(), because it will be separate from the core's trips table now and it has to be explicitly kept in sync with the latter. Signed-off-by:
-
Rafael J. Wysocki authored
Merge thermal core changes for 6.9: - Minor fixes for thermal governors (Rafael J. Wysocki, Di Shen). - Trip point handling fixes for the iwlwifi wireless driver (Rafael J. Wysocki). - Code cleanups (Rafael J. Wysocki, AngeloGioacchino Del Regno). * thermal-tmp: thermal: gov_power_allocator: Avoid overwriting PID coefficients from setup time thermal: sysfs: Fix up white space in trip_point_temp_store() iwlwifi: mvm: Use for_each_thermal_trip() for walking trip points iwlwifi: mvm: Populate trip table before registering thermal zone iwlwifi: mvm: Drop unused fw_trips_index[] from iwl_mvm_thermal_device thermal: core: Change governor name to const char pointer thermal: gov_bang_bang: Fix possible cooling device state ping-pong thermal: gov_fair_share: Fix dependency on trip points ordering
-
- 12 Feb, 2024 3 commits
-
-
Zhang Rui authored
CPU temperature can be negative in some cases. Thus the negative CPU temperature should not be considered as a failure. Fix intel_tcc_get_temp() and its users to support negative CPU temperature. Fixes: a3c1f066 ("thermal/intel: Introduce Intel TCC library") Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reviewed-by:
-
Di Shen authored
When the PID coefficients k_* are set via sysfs before the IPA algorithm is triggered then the coefficients would be overwritten after IPA throttle() is called. The old configuration values might be different than the new values estimated by the IPA internal algorithm. There might be a time delay when this overwriting happens. It depends on the thermal zone temperature value. The temperature value needs to cross the first trip point value then IPA algorithms start operating. Although, the PID coefficients setup time should not be affected or linked to any later operating phase and values must not be overwritten. This patch initializes params->sustainable_power when the governor binds to thermal zone to avoid overwriting k_*. The basic function won't be affected, as the k_* still can be estimated if the sustainable_power is modified. Signed-off-by:
Di Shen <di.shen@unisoc.com> Reviewed-by:
Lukasz Luba <lukasz.luba@arm.com> Signed-off-by:
-
Rafael J. Wysocki authored
Remove an excess tab character from an otherwise empty code line. No functional impact. Signed-off-by:
-
