From ca93bf607a44c1f009283dac4af7df0d9ae5e357 Mon Sep 17 00:00:00 2001 From: Christophe JAILLET Date: Sun, 28 Jan 2024 09:38:10 +0100 Subject: [PATCH 01/16] thermal/drivers/mediatek/lvts_thermal: Fix a memory leak in an error handling path If devm_krealloc() fails, then 'efuse' is leaking. So free it to avoid a leak. Fixes: f5f633b18234 ("thermal/drivers/mediatek: Add the Low Voltage Thermal Sensor driver") Signed-off-by: Christophe JAILLET Reviewed-by: Matthias Brugger Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/481d345233862d58c3c305855a93d0dbc2bbae7e.1706431063.git.christophe.jaillet@wanadoo.fr --- drivers/thermal/mediatek/lvts_thermal.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c index 98d9c80bd4c6..fd4bd650c77a 100644 --- a/drivers/thermal/mediatek/lvts_thermal.c +++ b/drivers/thermal/mediatek/lvts_thermal.c @@ -719,8 +719,10 @@ static int lvts_calibration_read(struct device *dev, struct lvts_domain *lvts_td lvts_td->calib = devm_krealloc(dev, lvts_td->calib, lvts_td->calib_len + len, GFP_KERNEL); - if (!lvts_td->calib) + if (!lvts_td->calib) { + kfree(efuse); return -ENOMEM; + } memcpy(lvts_td->calib + lvts_td->calib_len, efuse, len); From 371ed6263e2403068b359f0c07188548c2d70827 Mon Sep 17 00:00:00 2001 From: Frank Wunderlich Date: Thu, 7 Sep 2023 13:20:18 +0200 Subject: [PATCH 02/16] thermal/drivers/mediatek: Fix control buffer enablement on MT7896 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 33140e668b10. Cc: stable@vger.kernel.org Fixes: 33140e668b10 ("thermal/drivers/mediatek: Control buffer enablement tweaks") Signed-off-by: Frank Wunderlich Reviewed-by: Markus Schneider-Pargmann Reviewed-by: Daniel Golle Tested-by: Daniel Golle Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20230907112018.52811-1-linux@fw-web.de --- drivers/thermal/mediatek/auxadc_thermal.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/thermal/mediatek/auxadc_thermal.c b/drivers/thermal/mediatek/auxadc_thermal.c index 8b0edb204844..9ee2e7283435 100644 --- a/drivers/thermal/mediatek/auxadc_thermal.c +++ b/drivers/thermal/mediatek/auxadc_thermal.c @@ -690,6 +690,9 @@ static const struct mtk_thermal_data mt7986_thermal_data = { .adcpnp = mt7986_adcpnp, .sensor_mux_values = mt7986_mux_values, .version = MTK_THERMAL_V3, + .apmixed_buffer_ctl_reg = APMIXED_SYS_TS_CON1, + .apmixed_buffer_ctl_mask = GENMASK(31, 6) | BIT(3), + .apmixed_buffer_ctl_set = BIT(0), }; static bool mtk_thermal_temp_is_valid(int temp) From f492d8220f0cd2d773b75ad63749e9b20bd23b6c Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Thu, 15 Feb 2024 13:51:19 +0100 Subject: [PATCH 03/16] thermal: Drop spaces before TABs 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 Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/480478a53fd42621e97b2db36e181903cc0f53e3.1708001426.git.geert+renesas@glider.be --- drivers/thermal/Makefile | 2 +- drivers/thermal/st/st_thermal.h | 18 +++++++++--------- drivers/thermal/st/st_thermal_memmap.c | 2 +- drivers/thermal/thermal_of.c | 2 +- 4 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index d77d7fe99a84..5cdf7d68687f 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -43,7 +43,7 @@ obj-$(CONFIG_RCAR_GEN3_THERMAL) += rcar_gen3_thermal.o obj-$(CONFIG_RZG2L_THERMAL) += rzg2l_thermal.o obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o obj-y += samsung/ -obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o +obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o diff --git a/drivers/thermal/st/st_thermal.h b/drivers/thermal/st/st_thermal.h index 75a84e6ec6a7..8639d9165c9b 100644 --- a/drivers/thermal/st/st_thermal.h +++ b/drivers/thermal/st/st_thermal.h @@ -38,10 +38,10 @@ struct st_thermal_sensor; * * @power_ctrl: Function for powering on/off a sensor. Clock to the * sensor is also controlled from this function. - * @alloc_regfields: Allocate regmap register fields, specific to a sensor. - * @do_memmap_regmap: Memory map the thermal register space and init regmap + * @alloc_regfields: Allocate regmap register fields, specific to a sensor. + * @do_memmap_regmap: Memory map the thermal register space and init regmap * instance or find regmap instance. - * @register_irq: Register an interrupt handler for a sensor. + * @register_irq: Register an interrupt handler for a sensor. */ struct st_thermal_sensor_ops { int (*power_ctrl)(struct st_thermal_sensor *, enum st_thermal_power_state); @@ -56,15 +56,15 @@ struct st_thermal_sensor_ops { * * @reg_fields: Pointer to the regfields array for a sensor. * @sys_compat: Pointer to the syscon node compatible string. - * @ops: Pointer to private thermal ops for a sensor. - * @calibration_val: Default calibration value to be written to the DCORRECT + * @ops: Pointer to private thermal ops for a sensor. + * @calibration_val: Default calibration value to be written to the DCORRECT * register field for a sensor. - * @temp_adjust_val: Value to be added/subtracted from the data read from + * @temp_adjust_val: Value to be added/subtracted from the data read from * the sensor. If value needs to be added please provide a * positive value and if it is to be subtracted please - * provide a negative value. - * @crit_temp: The temperature beyond which the SoC should be shutdown - * to prevent damage. + * provide a negative value. + * @crit_temp: The temperature beyond which the SoC should be shutdown + * to prevent damage. */ struct st_thermal_compat_data { char *sys_compat; diff --git a/drivers/thermal/st/st_thermal_memmap.c b/drivers/thermal/st/st_thermal_memmap.c index e8cfa83b724a..29c2269b0fb3 100644 --- a/drivers/thermal/st/st_thermal_memmap.c +++ b/drivers/thermal/st/st_thermal_memmap.c @@ -27,7 +27,7 @@ static const struct reg_field st_mmap_thermal_regfields[MAX_REGFIELDS] = { * written simultaneously for powering on and off the temperature * sensor. regmap_update_bits() will be used to update the register. */ - [INT_THRESH_HI] = REG_FIELD(STIH416_MPE_INT_THRESH, 0, 7), + [INT_THRESH_HI] = REG_FIELD(STIH416_MPE_INT_THRESH, 0, 7), [DCORRECT] = REG_FIELD(STIH416_MPE_CONF, 5, 9), [OVERFLOW] = REG_FIELD(STIH416_MPE_STATUS, 9, 9), [DATA] = REG_FIELD(STIH416_MPE_STATUS, 11, 18), diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c index f1cbf9aa62cf..bc4b50fce70c 100644 --- a/drivers/thermal/thermal_of.c +++ b/drivers/thermal/thermal_of.c @@ -460,7 +460,7 @@ static void thermal_of_zone_unregister(struct thermal_zone_device *tz) * @ops: A set of thermal sensor ops * * Return: a valid thermal zone structure pointer on success. - * - EINVAL: if the device tree thermal description is malformed + * - EINVAL: if the device tree thermal description is malformed * - ENOMEM: if one structure can not be allocated * - Other negative errors are returned by the underlying called functions */ From dd01475a03b22a8393ff9ac7f43d67a1a608d2cf Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Thu, 4 Jan 2024 09:49:52 -0300 Subject: [PATCH 04/16] dt-bindings: thermal: qoriq-thermal: Adjust fsl,tmu-range min/maxItems 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 Reviewed-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240104124952.1975160-1-festevam@gmail.com --- Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml index 145744027234..d155d6799da6 100644 --- a/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/qoriq-thermal.yaml @@ -33,7 +33,8 @@ properties: description: | The values to be programmed into TTRnCR, as specified by the SoC reference manual. The first cell is TTR0CR, the second is TTR1CR, etc. - maxItems: 4 + minItems: 2 + maxItems: 7 fsl,tmu-calibration: $ref: /schemas/types.yaml#/definitions/uint32-matrix From f8cfe02a53e6ca991a0325ec6925510ac5c8690f Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Mon, 19 Feb 2024 15:36:33 +0000 Subject: [PATCH 05/16] soc: sunxi: sram: export register 0 for THS on H616 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: Andre Przywara Reviewed-by: Jernej Skrabec Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-2-andre.przywara@arm.com --- drivers/soc/sunxi/sunxi_sram.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/soc/sunxi/sunxi_sram.c b/drivers/soc/sunxi/sunxi_sram.c index 4458b2e0562b..6eb6cf06278e 100644 --- a/drivers/soc/sunxi/sunxi_sram.c +++ b/drivers/soc/sunxi/sunxi_sram.c @@ -287,6 +287,7 @@ EXPORT_SYMBOL(sunxi_sram_release); struct sunxi_sramc_variant { int num_emac_clocks; bool has_ldo_ctrl; + bool has_ths_offset; }; static const struct sunxi_sramc_variant sun4i_a10_sramc_variant = { @@ -308,8 +309,10 @@ static const struct sunxi_sramc_variant sun50i_a64_sramc_variant = { static const struct sunxi_sramc_variant sun50i_h616_sramc_variant = { .num_emac_clocks = 2, + .has_ths_offset = true, }; +#define SUNXI_SRAM_THS_OFFSET_REG 0x0 #define SUNXI_SRAM_EMAC_CLOCK_REG 0x30 #define SUNXI_SYS_LDO_CTRL_REG 0x150 @@ -318,6 +321,8 @@ static bool sunxi_sram_regmap_accessible_reg(struct device *dev, { const struct sunxi_sramc_variant *variant = dev_get_drvdata(dev); + if (reg == SUNXI_SRAM_THS_OFFSET_REG && variant->has_ths_offset) + return true; if (reg >= SUNXI_SRAM_EMAC_CLOCK_REG && reg < SUNXI_SRAM_EMAC_CLOCK_REG + variant->num_emac_clocks * 4) return true; @@ -327,6 +332,20 @@ static bool sunxi_sram_regmap_accessible_reg(struct device *dev, return false; } +static void sunxi_sram_lock(void *_lock) +{ + spinlock_t *lock = _lock; + + spin_lock(lock); +} + +static void sunxi_sram_unlock(void *_lock) +{ + spinlock_t *lock = _lock; + + spin_unlock(lock); +} + static struct regmap_config sunxi_sram_regmap_config = { .reg_bits = 32, .val_bits = 32, @@ -336,6 +355,9 @@ static struct regmap_config sunxi_sram_regmap_config = { /* other devices have no business accessing other registers */ .readable_reg = sunxi_sram_regmap_accessible_reg, .writeable_reg = sunxi_sram_regmap_accessible_reg, + .lock = sunxi_sram_lock, + .unlock = sunxi_sram_unlock, + .lock_arg = &sram_lock, }; static int __init sunxi_sram_probe(struct platform_device *pdev) From d1dc7ee560154c5e96f874796098c4cb391d5952 Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Mon, 19 Feb 2024 15:36:34 +0000 Subject: [PATCH 06/16] dt-bindings: thermal: sun8i: Add H616 THS controller 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: Martin Botka Signed-off-by: Andre Przywara Reviewed-by: Krzysztof Kozlowski Acked-by: Vasily Khoruzhick Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-3-andre.przywara@arm.com --- .../thermal/allwinner,sun8i-a83t-ths.yaml | 34 +++++++++++++------ 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index 9b2272a9ec15..6b3aea6d73b0 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -21,6 +21,7 @@ properties: - allwinner,sun50i-a100-ths - allwinner,sun50i-h5-ths - allwinner,sun50i-h6-ths + - allwinner,sun50i-h616-ths clocks: minItems: 1 @@ -50,6 +51,10 @@ properties: nvmem-cell-names: const: calibration + allwinner,sram: + maxItems: 1 + description: phandle to device controlling temperate offset SYS_CFG register + # See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details "#thermal-sensor-cells": enum: @@ -65,6 +70,7 @@ allOf: - allwinner,sun20i-d1-ths - allwinner,sun50i-a100-ths - allwinner,sun50i-h6-ths + - allwinner,sun50i-h616-ths then: properties: @@ -82,6 +88,17 @@ allOf: clock-names: minItems: 2 + - if: + not: + properties: + compatible: + contains: + const: allwinner,sun50i-h616-ths + + then: + properties: + allwinner,sram: false + - if: properties: compatible: @@ -101,17 +118,12 @@ allOf: const: 1 - if: - properties: - compatible: - contains: - enum: - - allwinner,sun8i-h3-ths - - allwinner,sun8i-r40-ths - - allwinner,sun20i-d1-ths - - allwinner,sun50i-a64-ths - - allwinner,sun50i-a100-ths - - allwinner,sun50i-h5-ths - - allwinner,sun50i-h6-ths + not: + properties: + compatible: + contains: + enum: + - allwinner,sun8i-a83t-ths then: required: From d7bf0a1ada00021a09dca328e084f77d97ff13b4 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Mon, 19 Feb 2024 15:36:35 +0000 Subject: [PATCH 07/16] thermal/drivers/sun8i: Explain unknown H6 register value 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: Andre Przywara Reviewed-by: Jernej Skrabec Acked-by: Vasily Khoruzhick Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-4-andre.przywara@arm.com --- drivers/thermal/sun8i_thermal.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c index 6a8e386dbc8d..42bee03c4e50 100644 --- a/drivers/thermal/sun8i_thermal.c +++ b/drivers/thermal/sun8i_thermal.c @@ -50,7 +50,8 @@ #define SUN8I_THS_CTRL2_T_ACQ1(x) ((GENMASK(15, 0) & (x)) << 16) #define SUN8I_THS_DATA_IRQ_STS(x) BIT(x + 8) -#define SUN50I_THS_CTRL0_T_ACQ(x) ((GENMASK(15, 0) & (x)) << 16) +#define SUN50I_THS_CTRL0_T_ACQ(x) (GENMASK(15, 0) & ((x) - 1)) +#define SUN50I_THS_CTRL0_T_SAMPLE_PER(x) ((GENMASK(15, 0) & ((x) - 1)) << 16) #define SUN50I_THS_FILTER_EN BIT(2) #define SUN50I_THS_FILTER_TYPE(x) (GENMASK(1, 0) & (x)) #define SUN50I_H6_THS_PC_TEMP_PERIOD(x) ((GENMASK(19, 0) & (x)) << 12) @@ -410,25 +411,27 @@ static int sun8i_h3_thermal_init(struct ths_device *tmdev) return 0; } -/* - * Without this undocumented value, the returned temperatures would - * be higher than real ones by about 20C. - */ -#define SUN50I_H6_CTRL0_UNK 0x0000002f - static int sun50i_h6_thermal_init(struct ths_device *tmdev) { int val; /* - * T_acq = 20us - * clkin = 24MHz - * - * x = T_acq * clkin - 1 - * = 479 + * The manual recommends an overall sample frequency of 50 KHz (20us, + * 480 cycles at 24 MHz), which provides plenty of time for both the + * acquisition time (>24 cycles) and the actual conversion time + * (>14 cycles). + * The lower half of the CTRL register holds the "acquire time", in + * clock cycles, which the manual recommends to be 2us: + * 24MHz * 2us = 48 cycles. + * The high half of THS_CTRL encodes the sample frequency, in clock + * cycles: 24MHz * 20us = 480 cycles. + * This is explained in the H616 manual, but apparently wrongly + * described in the H6 manual, although the BSP code does the same + * for both SoCs. */ regmap_write(tmdev->regmap, SUN50I_THS_CTRL0, - SUN50I_H6_CTRL0_UNK | SUN50I_THS_CTRL0_T_ACQ(479)); + SUN50I_THS_CTRL0_T_ACQ(48) | + SUN50I_THS_CTRL0_T_SAMPLE_PER(480)); /* average over 4 samples */ regmap_write(tmdev->regmap, SUN50I_H6_THS_MFC, SUN50I_THS_FILTER_EN | From 63e39fcaa6db821b05103b55483a44d0c5b43abb Mon Sep 17 00:00:00 2001 From: Maksim Kiselev Date: Mon, 19 Feb 2024 15:36:36 +0000 Subject: [PATCH 08/16] thermal/drivers/sun8i: Extend H6 calibration to support 4 sensors 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: Martin Botka Signed-off-by: Martin Botka Signed-off-by: Maksim Kiselev Reviewed-by: Andre Przywara Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Acked-by: Vasily Khoruzhick Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-5-andre.przywara@arm.com --- drivers/thermal/sun8i_thermal.c | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c index 42bee03c4e50..c919b0fd5e16 100644 --- a/drivers/thermal/sun8i_thermal.c +++ b/drivers/thermal/sun8i_thermal.c @@ -222,16 +222,21 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev, struct device *dev = tmdev->dev; int i, ft_temp; - if (!caldata[0] || callen < 2 + 2 * tmdev->chip->sensor_num) + if (!caldata[0]) return -EINVAL; /* * efuse layout: * - * 0 11 16 32 - * +-------+-------+-------+ - * |temp| |sensor0|sensor1| - * +-------+-------+-------+ + * 0 11 16 27 32 43 48 57 + * +----------+-----------+-----------+-----------+ + * | temp | |sensor0| |sensor1| |sensor2| | + * +----------+-----------+-----------+-----------+ + * ^ ^ ^ + * | | | + * | | sensor3[11:8] + * | sensor3[7:4] + * sensor3[3:0] * * The calibration data on the H6 is the ambient temperature and * sensor values that are filled during the factory test stage. @@ -244,9 +249,16 @@ static int sun50i_h6_ths_calibrate(struct ths_device *tmdev, ft_temp = (caldata[0] & FT_TEMP_MASK) * 100; for (i = 0; i < tmdev->chip->sensor_num; i++) { - int sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK; - int cdata, offset; - int sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg); + int sensor_reg, sensor_temp, cdata, offset; + + if (i == 3) + sensor_reg = (caldata[1] >> 12) + | ((caldata[2] >> 12) << 4) + | ((caldata[3] >> 12) << 8); + else + sensor_reg = caldata[i + 1] & TEMP_CALIB_MASK; + + sensor_temp = tmdev->chip->calc_temp(tmdev, i, sensor_reg); /* * Calibration data is CALIBRATE_DEFAULT - (calculated From bd0b451bd40fbe42d5d36e3740c489d503636d48 Mon Sep 17 00:00:00 2001 From: Andre Przywara Date: Mon, 19 Feb 2024 15:36:37 +0000 Subject: [PATCH 09/16] thermal/drivers/sun8i: Add SRAM register access code 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: Andre Przywara Acked-by: Vasily Khoruzhick Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-6-andre.przywara@arm.com --- drivers/thermal/sun8i_thermal.c | 51 +++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c index c919b0fd5e16..c157e4fbf963 100644 --- a/drivers/thermal/sun8i_thermal.c +++ b/drivers/thermal/sun8i_thermal.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -66,6 +67,7 @@ struct tsensor { struct ths_thermal_chip { bool has_mod_clk; bool has_bus_clk_reset; + bool needs_sram; int sensor_num; int offset; int scale; @@ -83,12 +85,16 @@ struct ths_device { const struct ths_thermal_chip *chip; struct device *dev; struct regmap *regmap; + struct regmap_field *sram_regmap_field; struct reset_control *reset; struct clk *bus_clk; struct clk *mod_clk; struct tsensor sensor[MAX_SENSOR_NUM]; }; +/* The H616 needs to have a bit 16 in the SRAM control register cleared. */ +static const struct reg_field sun8i_ths_sram_reg_field = REG_FIELD(0x0, 16, 16); + /* Temp Unit: millidegree Celsius */ static int sun8i_ths_calc_temp(struct ths_device *tmdev, int id, int reg) @@ -337,6 +343,34 @@ static void sun8i_ths_reset_control_assert(void *data) reset_control_assert(data); } +static struct regmap *sun8i_ths_get_sram_regmap(struct device_node *node) +{ + struct device_node *sram_node; + struct platform_device *sram_pdev; + struct regmap *regmap = NULL; + + sram_node = of_parse_phandle(node, "allwinner,sram", 0); + if (!sram_node) + return ERR_PTR(-ENODEV); + + sram_pdev = of_find_device_by_node(sram_node); + if (!sram_pdev) { + /* platform device might not be probed yet */ + regmap = ERR_PTR(-EPROBE_DEFER); + goto out_put_node; + } + + /* If no regmap is found then the other device driver is at fault */ + regmap = dev_get_regmap(&sram_pdev->dev, NULL); + if (!regmap) + regmap = ERR_PTR(-EINVAL); + + platform_device_put(sram_pdev); +out_put_node: + of_node_put(sram_node); + return regmap; +} + static int sun8i_ths_resource_init(struct ths_device *tmdev) { struct device *dev = tmdev->dev; @@ -381,6 +415,19 @@ static int sun8i_ths_resource_init(struct ths_device *tmdev) if (ret) return ret; + if (tmdev->chip->needs_sram) { + struct regmap *regmap; + + regmap = sun8i_ths_get_sram_regmap(dev->of_node); + if (IS_ERR(regmap)) + return PTR_ERR(regmap); + tmdev->sram_regmap_field = devm_regmap_field_alloc(dev, + regmap, + sun8i_ths_sram_reg_field); + if (IS_ERR(tmdev->sram_regmap_field)) + return PTR_ERR(tmdev->sram_regmap_field); + } + ret = sun8i_ths_calibrate(tmdev); if (ret) return ret; @@ -427,6 +474,10 @@ static int sun50i_h6_thermal_init(struct ths_device *tmdev) { int val; + /* The H616 needs to have a bit in the SRAM control register cleared. */ + if (tmdev->sram_regmap_field) + regmap_field_write(tmdev->sram_regmap_field, 0); + /* * The manual recommends an overall sample frequency of 50 KHz (20us, * 480 cycles at 24 MHz), which provides plenty of time for both the From 83620b3b04c663663c5f75d44db7a16077e4f02b Mon Sep 17 00:00:00 2001 From: Martin Botka Date: Mon, 19 Feb 2024 15:36:38 +0000 Subject: [PATCH 10/16] thermal/drivers/sun8i: Add support for H616 THS controller 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 Signed-off-by: Andre Przywara Acked-by: Vasily Khoruzhick Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240219153639.179814-7-andre.przywara@arm.com --- drivers/thermal/sun8i_thermal.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c index c157e4fbf963..63a7d2df3d6e 100644 --- a/drivers/thermal/sun8i_thermal.c +++ b/drivers/thermal/sun8i_thermal.c @@ -684,6 +684,20 @@ static const struct ths_thermal_chip sun20i_d1_ths = { .calc_temp = sun8i_ths_calc_temp, }; +static const struct ths_thermal_chip sun50i_h616_ths = { + .sensor_num = 4, + .has_bus_clk_reset = true, + .needs_sram = true, + .ft_deviation = 8000, + .offset = 263655, + .scale = 810, + .temp_data_base = SUN50I_H6_THS_TEMP_DATA, + .calibrate = sun50i_h6_ths_calibrate, + .init = sun50i_h6_thermal_init, + .irq_ack = sun50i_h6_irq_ack, + .calc_temp = sun8i_ths_calc_temp, +}; + static const struct of_device_id of_ths_match[] = { { .compatible = "allwinner,sun8i-a83t-ths", .data = &sun8i_a83t_ths }, { .compatible = "allwinner,sun8i-h3-ths", .data = &sun8i_h3_ths }, @@ -693,6 +707,7 @@ static const struct of_device_id of_ths_match[] = { { .compatible = "allwinner,sun50i-h5-ths", .data = &sun50i_h5_ths }, { .compatible = "allwinner,sun50i-h6-ths", .data = &sun50i_h6_ths }, { .compatible = "allwinner,sun20i-d1-ths", .data = &sun20i_d1_ths }, + { .compatible = "allwinner,sun50i-h616-ths", .data = &sun50i_h616_ths }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, of_ths_match); From 79d998421d494a68db81f05977d2c22fb06cd627 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Tue, 23 Jan 2024 23:33:07 +0000 Subject: [PATCH 11/16] thermal/drivers/sun8i: Don't fail probe due to zone registration failure 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 Acked-by: Jernej Skrabec Signed-off-by: Mark Brown Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240123-thermal-sun8i-registration-v3-1-3e5771b1bbdd@kernel.org --- drivers/thermal/sun8i_thermal.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c index 63a7d2df3d6e..3203d8bd13a8 100644 --- a/drivers/thermal/sun8i_thermal.c +++ b/drivers/thermal/sun8i_thermal.c @@ -195,6 +195,9 @@ static irqreturn_t sun8i_irq_thread(int irq, void *data) int i; for_each_set_bit(i, &irq_bitmap, tmdev->chip->sensor_num) { + /* We allow some zones to not register. */ + if (IS_ERR(tmdev->sensor[i].tzd)) + continue; thermal_zone_device_update(tmdev->sensor[i].tzd, THERMAL_EVENT_UNSPECIFIED); } @@ -531,8 +534,17 @@ static int sun8i_ths_register(struct ths_device *tmdev) i, &tmdev->sensor[i], &ths_ops); - if (IS_ERR(tmdev->sensor[i].tzd)) - return PTR_ERR(tmdev->sensor[i].tzd); + + /* + * If an individual zone fails to register for reasons + * other than probe deferral (eg, a bad DT) then carry + * on, other zones might register successfully. + */ + if (IS_ERR(tmdev->sensor[i].tzd)) { + if (PTR_ERR(tmdev->sensor[i].tzd) == -EPROBE_DEFER) + return PTR_ERR(tmdev->sensor[i].tzd); + continue; + } devm_thermal_add_hwmon_sysfs(tmdev->dev, tmdev->sensor[i].tzd); } From 4d0642074c67ed9928e9d68734ace439aa06e403 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Mon, 26 Feb 2024 08:36:57 +0800 Subject: [PATCH 12/16] thermal/drivers/qoriq: Fix getting tmu range 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: f12d60c81fce ("thermal/drivers/qoriq: Support version 2.1") Tested-by: Sascha Hauer Signed-off-by: Peng Fan Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240226003657.3012880-1-peng.fan@oss.nxp.com --- drivers/thermal/qoriq_thermal.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c index ccc2eea7f9f5..404f01cca4da 100644 --- a/drivers/thermal/qoriq_thermal.c +++ b/drivers/thermal/qoriq_thermal.c @@ -57,6 +57,9 @@ #define REGS_TTRnCR(n) (0xf10 + 4 * (n)) /* Temperature Range n * Control Register */ +#define NUM_TTRCR_V1 4 +#define NUM_TTRCR_MAX 16 + #define REGS_IPBRR(n) (0xbf8 + 4 * (n)) /* IP Block Revision * Register n */ @@ -71,6 +74,7 @@ struct qoriq_sensor { struct qoriq_tmu_data { int ver; + u32 ttrcr[NUM_TTRCR_MAX]; struct regmap *regmap; struct clk *clk; struct qoriq_sensor sensor[SITES_MAX]; @@ -182,17 +186,17 @@ static int qoriq_tmu_calibration(struct device *dev, struct qoriq_tmu_data *data) { int i, val, len; - u32 range[4]; const u32 *calibration; struct device_node *np = dev->of_node; len = of_property_count_u32_elems(np, "fsl,tmu-range"); - if (len < 0 || len > 4) { + if (len < 0 || (data->ver == TMU_VER1 && len > NUM_TTRCR_V1) || + (data->ver > TMU_VER1 && len > NUM_TTRCR_MAX)) { dev_err(dev, "invalid range data.\n"); return len; } - val = of_property_read_u32_array(np, "fsl,tmu-range", range, len); + val = of_property_read_u32_array(np, "fsl,tmu-range", data->ttrcr, len); if (val != 0) { dev_err(dev, "failed to read range data.\n"); return val; @@ -200,7 +204,7 @@ static int qoriq_tmu_calibration(struct device *dev, /* Init temperature range registers */ for (i = 0; i < len; i++) - regmap_write(data->regmap, REGS_TTRnCR(i), range[i]); + regmap_write(data->regmap, REGS_TTRnCR(i), data->ttrcr[i]); calibration = of_get_property(np, "fsl,tmu-calibration", &len); if (calibration == NULL || len % 8) { From 8d5d6abf28ae67c0062de9983254f1a5b6964961 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Thu, 25 Jan 2024 13:11:15 +0100 Subject: [PATCH 13/16] dt-bindings: thermal-zones: Don't require polling-delay(-passive) 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: Konrad Dybcio Reviewed-by: Conor Dooley Reviewed-by: Bjorn Andersson Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-1-3c9d4dced138@linaro.org --- Documentation/devicetree/bindings/thermal/thermal-zones.yaml | 2 -- 1 file changed, 2 deletions(-) diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index dbd52620d293..68398e7e8655 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -228,8 +228,6 @@ patternProperties: additionalProperties: false required: - - polling-delay - - polling-delay-passive - thermal-sensors - trips From 488164006a281986d95abbc4b26e340c19c4c85b Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Thu, 25 Jan 2024 13:11:16 +0100 Subject: [PATCH 14/16] thermal/of: Assume polling-delay(-passive) 0 when absent 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 Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20240125-topic-thermal-v1-2-3c9d4dced138@linaro.org --- drivers/thermal/thermal_of.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/thermal/thermal_of.c b/drivers/thermal/thermal_of.c index bc4b50fce70c..aa34b6e82e26 100644 --- a/drivers/thermal/thermal_of.c +++ b/drivers/thermal/thermal_of.c @@ -227,14 +227,18 @@ static int thermal_of_monitor_init(struct device_node *np, int *delay, int *pdel int ret; ret = of_property_read_u32(np, "polling-delay-passive", pdelay); - if (ret < 0) { - pr_err("%pOFn: missing polling-delay-passive property\n", np); + if (ret == -EINVAL) { + *pdelay = 0; + } else if (ret < 0) { + pr_err("%pOFn: Couldn't get polling-delay-passive: %d\n", np, ret); return ret; } ret = of_property_read_u32(np, "polling-delay", delay); - if (ret < 0) { - pr_err("%pOFn: missing polling-delay property\n", np); + if (ret == -EINVAL) { + *delay = 0; + } else if (ret < 0) { + pr_err("%pOFn: Couldn't get polling-delay: %d\n", np, ret); return ret; } From 6796c1b68fa92c303923812a0658f3afe8366db2 Mon Sep 17 00:00:00 2001 From: Duy Nguyen Date: Wed, 6 Mar 2024 11:56:02 +0100 Subject: [PATCH 15/16] dt-bindings: thermal: rcar-gen3-thermal: Add r8a779h0 support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document support for the Thermal Sensor/Chip Internal Voltage Monitor/Core Voltage Monitor (THS/CIVM/CVM) on the Renesas R-Car V4M (R8A779H0) SoC. Just like on other R-Car Gen4 SoCs, interrupts are not routed to the INTC-AP (GIC) but to the Error Control Module (ECM). Signed-off-by: Duy Nguyen Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Acked-by: Conor Dooley Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/b3d135f8b63b9fe2d0f0aa2e48c8a2211b2e947e.1709722342.git.geert+renesas@glider.be --- .../devicetree/bindings/thermal/rcar-gen3-thermal.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml index ecf276fd155c..6a81cb6e11bc 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-gen3-thermal.yaml @@ -29,6 +29,7 @@ properties: - renesas,r8a779a0-thermal # R-Car V3U - renesas,r8a779f0-thermal # R-Car S4-8 - renesas,r8a779g0-thermal # R-Car V4H + - renesas,r8a779h0-thermal # R-Car V4M reg: true @@ -90,6 +91,7 @@ else: enum: - renesas,r8a779f0-thermal - renesas,r8a779g0-thermal + - renesas,r8a779h0-thermal then: required: - interrupts From 1828c1c17bb2adf3a3f26abc69cb3fe971eac0e4 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 6 Mar 2024 11:56:03 +0100 Subject: [PATCH 16/16] thermal/drivers/rcar_gen3: Add support for R-Car V4M MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add support for the Thermal Sensor/Chip Internal Voltage Monitor/Core Voltage Monitor (THS/CIVM/CVM) on the Renesas R-Car V4M (R8A779H0) SoC. The conversion formulas for R-Car V4M are the same as for other R-Car Gen4 SoCs. Based on a patch in the BSP by Duy Nguyen. Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/bd5b002a802c1e058e0048592f17862db1d04263.1709722342.git.geert+renesas@glider.be --- drivers/thermal/rcar_gen3_thermal.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/thermal/rcar_gen3_thermal.c b/drivers/thermal/rcar_gen3_thermal.c index cafcb6d6e235..a764cb1115a5 100644 --- a/drivers/thermal/rcar_gen3_thermal.c +++ b/drivers/thermal/rcar_gen3_thermal.c @@ -428,6 +428,10 @@ static const struct of_device_id rcar_gen3_thermal_dt_ids[] = { .compatible = "renesas,r8a779g0-thermal", .data = &rcar_gen4_thermal_info, }, + { + .compatible = "renesas,r8a779h0-thermal", + .data = &rcar_gen4_thermal_info, + }, {}, }; MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);