* [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ and "Add LVTS's AP thermal domain support for mt8195" : https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ Based on top of thermal/linux-next : base-commit: 6828e402d06f7c574430b61c05db784cd847b19f Depends on these patches as they are not yet applyied to thermal/linux-next branch : [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ Balsam CHIHI (4): dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 thermal/drivers/mediatek/lvts_thermal: Add mt8192 support arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes arm64: dts: mediatek: mt8192: Add temperature mitigation threshold arch/arm64/boot/dts/mediatek/mt8192.dtsi | 454 ++++++++++++++++++ drivers/thermal/mediatek/lvts_thermal.c | 106 +++- .../thermal/mediatek,lvts-thermal.h | 19 + 3 files changed, 577 insertions(+), 2 deletions(-) base-commit: 6828e402d06f7c574430b61c05db784cd847b19f prerequisite-patch-id: 73be949bd16979769e5b94905b244dcee4a8f687 prerequisite-patch-id: 9076e9b3bd3cc411b7b80344211364db5f0cca17 prerequisite-patch-id: e220d6ae26786f524c249588433f02e5f5f906ad prerequisite-patch-id: 58e295ae36ad4784f3eb3830412f35dad31bb8b6 prerequisite-patch-id: d23d83a946e5b876ef01a717fd51b07df1fa08dd prerequisite-patch-id: d67f2455eef1c4a9ecc460dbf3c2e3ad47d213ec prerequisite-patch-id: b407d2998e57678952128b3a4bac92a379132b09 prerequisite-patch-id: fbb9212ce8c3530da17d213f56fa334ce4fa1b2b prerequisite-patch-id: 5db9eed2659028cf4419f2de3d093af7df6c2dad prerequisite-patch-id: a83c00c628605d1c8fbe1d97074f9f28efb1bcfc -- 2.34.1 ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ and "Add LVTS's AP thermal domain support for mt8195" : https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ Based on top of thermal/linux-next : base-commit: 6828e402d06f7c574430b61c05db784cd847b19f Depends on these patches as they are not yet applyied to thermal/linux-next branch : [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ Balsam CHIHI (4): dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 thermal/drivers/mediatek/lvts_thermal: Add mt8192 support arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes arm64: dts: mediatek: mt8192: Add temperature mitigation threshold arch/arm64/boot/dts/mediatek/mt8192.dtsi | 454 ++++++++++++++++++ drivers/thermal/mediatek/lvts_thermal.c | 106 +++- .../thermal/mediatek,lvts-thermal.h | 19 + 3 files changed, 577 insertions(+), 2 deletions(-) base-commit: 6828e402d06f7c574430b61c05db784cd847b19f prerequisite-patch-id: 73be949bd16979769e5b94905b244dcee4a8f687 prerequisite-patch-id: 9076e9b3bd3cc411b7b80344211364db5f0cca17 prerequisite-patch-id: e220d6ae26786f524c249588433f02e5f5f906ad prerequisite-patch-id: 58e295ae36ad4784f3eb3830412f35dad31bb8b6 prerequisite-patch-id: d23d83a946e5b876ef01a717fd51b07df1fa08dd prerequisite-patch-id: d67f2455eef1c4a9ecc460dbf3c2e3ad47d213ec prerequisite-patch-id: b407d2998e57678952128b3a4bac92a379132b09 prerequisite-patch-id: fbb9212ce8c3530da17d213f56fa334ce4fa1b2b prerequisite-patch-id: 5db9eed2659028cf4419f2de3d093af7df6c2dad prerequisite-patch-id: a83c00c628605d1c8fbe1d97074f9f28efb1bcfc -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 2023-03-07 16:34 ` bchihi @ 2023-03-07 16:34 ` bchihi -1 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add LVTS thermal controller definition for MT8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- .../thermal/mediatek,lvts-thermal.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/dt-bindings/thermal/mediatek,lvts-thermal.h b/include/dt-bindings/thermal/mediatek,lvts-thermal.h index 8fa5a46675c4..5e9eb6217426 100644 --- a/include/dt-bindings/thermal/mediatek,lvts-thermal.h +++ b/include/dt-bindings/thermal/mediatek,lvts-thermal.h @@ -26,4 +26,23 @@ #define MT8195_AP_CAM0 15 #define MT8195_AP_CAM1 16 +#define MT8192_MCU_BIG_CPU0 0 +#define MT8192_MCU_BIG_CPU1 1 +#define MT8192_MCU_BIG_CPU2 2 +#define MT8192_MCU_BIG_CPU3 3 +#define MT8192_MCU_LITTLE_CPU0 4 +#define MT8192_MCU_LITTLE_CPU1 5 +#define MT8192_MCU_LITTLE_CPU2 6 +#define MT8192_MCU_LITTLE_CPU3 7 + +#define MT8192_AP_VPU0 8 +#define MT8192_AP_VPU1 9 +#define MT8192_AP_GPU0 10 +#define MT8192_AP_GPU1 11 +#define MT8192_AP_INFRA 12 +#define MT8192_AP_CAM 13 +#define MT8192_AP_MD0 14 +#define MT8192_AP_MD1 15 +#define MT8192_AP_MD2 16 + #endif /* __MEDIATEK_LVTS_DT_H */ -- 2.34.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add LVTS thermal controller definition for MT8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- .../thermal/mediatek,lvts-thermal.h | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/include/dt-bindings/thermal/mediatek,lvts-thermal.h b/include/dt-bindings/thermal/mediatek,lvts-thermal.h index 8fa5a46675c4..5e9eb6217426 100644 --- a/include/dt-bindings/thermal/mediatek,lvts-thermal.h +++ b/include/dt-bindings/thermal/mediatek,lvts-thermal.h @@ -26,4 +26,23 @@ #define MT8195_AP_CAM0 15 #define MT8195_AP_CAM1 16 +#define MT8192_MCU_BIG_CPU0 0 +#define MT8192_MCU_BIG_CPU1 1 +#define MT8192_MCU_BIG_CPU2 2 +#define MT8192_MCU_BIG_CPU3 3 +#define MT8192_MCU_LITTLE_CPU0 4 +#define MT8192_MCU_LITTLE_CPU1 5 +#define MT8192_MCU_LITTLE_CPU2 6 +#define MT8192_MCU_LITTLE_CPU3 7 + +#define MT8192_AP_VPU0 8 +#define MT8192_AP_VPU1 9 +#define MT8192_AP_GPU0 10 +#define MT8192_AP_GPU1 11 +#define MT8192_AP_INFRA 12 +#define MT8192_AP_CAM 13 +#define MT8192_AP_MD0 14 +#define MT8192_AP_MD1 15 +#define MT8192_AP_MD2 16 + #endif /* __MEDIATEK_LVTS_DT_H */ -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 2023-03-07 16:34 ` bchihi @ 2023-03-08 9:20 ` AngeloGioacchino Del Regno -1 siblings, 0 replies; 46+ messages in thread From: AngeloGioacchino Del Regno @ 2023-03-08 9:20 UTC (permalink / raw) To: bchihi, daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS thermal controller definition for MT8192. > > Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 @ 2023-03-08 9:20 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 46+ messages in thread From: AngeloGioacchino Del Regno @ 2023-03-08 9:20 UTC (permalink / raw) To: bchihi, daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS thermal controller definition for MT8192. > > Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 2023-03-07 16:34 ` bchihi @ 2023-03-09 16:17 ` Krzysztof Kozlowski -1 siblings, 0 replies; 46+ messages in thread From: Krzysztof Kozlowski @ 2023-03-09 16:17 UTC (permalink / raw) To: bchihi, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On 07/03/2023 17:34, bchihi@baylibre.com wrote: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS thermal controller definition for MT8192. > > Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> > --- Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition for mt8192 @ 2023-03-09 16:17 ` Krzysztof Kozlowski 0 siblings, 0 replies; 46+ messages in thread From: Krzysztof Kozlowski @ 2023-03-09 16:17 UTC (permalink / raw) To: bchihi, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On 07/03/2023 17:34, bchihi@baylibre.com wrote: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS thermal controller definition for MT8192. > > Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> > --- Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support 2023-03-07 16:34 ` bchihi @ 2023-03-07 16:34 ` bchihi -1 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add LVTS Driver support for MT8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- drivers/thermal/mediatek/lvts_thermal.c | 106 +++++++++++++++++++++++- 1 file changed, 104 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c index 7565def6b27c..b505c6b49031 100644 --- a/drivers/thermal/mediatek/lvts_thermal.c +++ b/drivers/thermal/mediatek/lvts_thermal.c @@ -80,6 +80,7 @@ #define LVTS_MSR_FILTERED_MODE 1 #define LVTS_HW_SHUTDOWN_MT8195 105000 +#define LVTS_HW_SHUTDOWN_MT8192 105000 static int golden_temp = LVTS_GOLDEN_TEMP_DEFAULT; static int coeff_b = LVTS_COEFF_B; @@ -528,7 +529,7 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * The efuse blob values follows the sensor enumeration per thermal * controller. The decoding of the stream is as follow: * - * stream index map for MCU Domain : + * stream index map for MCU Domain mt8195/mt8192 : * * <-----mcu-tc#0-----> <-----sensor#0-----> <-----sensor#1-----> * 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 | 0x08 | 0x09 @@ -539,7 +540,7 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * <-----mcu-tc#2-----> <-----sensor#4-----> <-----sensor#5-----> <-----sensor#6-----> <-----sensor#7-----> * 0x13 | 0x14 | 0x15 | 0x16 | 0x17 | 0x18 | 0x19 | 0x1A | 0x1B | 0x1C | 0x1D | 0x1E | 0x1F | 0x20 | 0x21 * - * stream index map for AP Domain : + * stream index map for AP Domain mt8195/mt8192 : * * <-----ap--tc#0-----> <-----sensor#0-----> <-----sensor#1-----> * 0x22 | 0x23 | 0x24 | 0x25 | 0x26 | 0x27 | 0x28 | 0x29 | 0x2A @@ -547,12 +548,22 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * <-----ap--tc#1-----> <-----sensor#2-----> <-----sensor#3-----> * 0x2B | 0x2C | 0x2D | 0x2E | 0x2F | 0x30 | 0x31 | 0x32 | 0x33 * + * stream index map for AP Domain mt8195 : + * * <-----ap--tc#2-----> <-----sensor#4-----> <-----sensor#5-----> <-----sensor#6-----> * 0x34 | 0x35 | 0x36 | 0x37 | 0x38 | 0x39 | 0x3A | 0x3B | 0x3C | 0x3D | 0x3E | 0x3F * * <-----ap--tc#3-----> <-----sensor#7-----> <-----sensor#8-----> * 0x40 | 0x41 | 0x42 | 0x43 | 0x44 | 0x45 | 0x46 | 0x47 | 0x48 * + * stream index map for AP Domain mt8192 : + * + * <-----ap--tc#2-----> <-----sensor#4-----> <-----sensor#5-----> + * 0x34 | 0x35 | 0x36 | 0x37 | 0x38 | 0x39 | 0x3A | 0x3B | 0x3C + * + * <-----ap--tc#3-----> <-----sensor#6-----> <-----sensor#7-----> <-----sensor#8-----> + * 0x3D | 0x3E | 0x3F | 0x40 | 0x41 | 0x42 | 0x43 | 0x44 | 0x45 | 0x46 | 0x47 | 0x48 + * * The data description gives the offset of the calibration data in * this bytes stream for each sensor. */ @@ -1246,6 +1257,85 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { } }; +static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { + { + .cal_offset = { 0x04, 0x07 }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_BIG_CPU0 }, + { .dt_id = MT8192_MCU_BIG_CPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x0, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x0d, 0x10 }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_BIG_CPU2 }, + { .dt_id = MT8192_MCU_BIG_CPU3 } + }, + .num_lvts_sensor = 2, + .offset = 0x100, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_LITTLE_CPU0 }, + { .dt_id = MT8192_MCU_LITTLE_CPU1 }, + { .dt_id = MT8192_MCU_LITTLE_CPU2 }, + { .dt_id = MT8192_MCU_LITTLE_CPU3 } + }, + .num_lvts_sensor = 4, + .offset = 0x200, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + } +}; + +static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { + { + .cal_offset = { 0x25, 0x28 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_VPU0 }, + { .dt_id = MT8192_AP_VPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x0, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x2e, 0x31 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_GPU0 }, + { .dt_id = MT8192_AP_GPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x100, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x37, 0x3a }, + .lvts_sensor = { + { .dt_id = MT8192_AP_INFRA }, + { .dt_id = MT8192_AP_CAM }, + }, + .num_lvts_sensor = 2, + .offset = 0x200, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x40, 0x43, 0x46 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_MD0 }, + { .dt_id = MT8192_AP_MD1 }, + { .dt_id = MT8192_AP_MD2 } + }, + .num_lvts_sensor = 3, + .offset = 0x300, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + } +}; + static const struct lvts_data mt8195_lvts_mcu_data = { .lvts_ctrl = mt8195_lvts_mcu_data_ctrl, .num_lvts_ctrl = ARRAY_SIZE(mt8195_lvts_mcu_data_ctrl), @@ -1256,9 +1346,21 @@ static const struct lvts_data mt8195_lvts_ap_data = { .num_lvts_ctrl = ARRAY_SIZE(mt8195_lvts_ap_data_ctrl), }; +static const struct lvts_data mt8192_lvts_mcu_data = { + .lvts_ctrl = mt8192_lvts_mcu_data_ctrl, + .num_lvts_ctrl = ARRAY_SIZE(mt8192_lvts_mcu_data_ctrl), +}; + +static const struct lvts_data mt8192_lvts_ap_data = { + .lvts_ctrl = mt8192_lvts_ap_data_ctrl, + .num_lvts_ctrl = ARRAY_SIZE(mt8192_lvts_ap_data_ctrl), +}; + static const struct of_device_id lvts_of_match[] = { { .compatible = "mediatek,mt8195-lvts-mcu", .data = &mt8195_lvts_mcu_data }, { .compatible = "mediatek,mt8195-lvts-ap", .data = &mt8195_lvts_ap_data }, + { .compatible = "mediatek,mt8192-lvts-mcu", .data = &mt8192_lvts_mcu_data }, + { .compatible = "mediatek,mt8192-lvts-ap", .data = &mt8192_lvts_ap_data }, {}, }; MODULE_DEVICE_TABLE(of, lvts_of_match); -- 2.34.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add LVTS Driver support for MT8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- drivers/thermal/mediatek/lvts_thermal.c | 106 +++++++++++++++++++++++- 1 file changed, 104 insertions(+), 2 deletions(-) diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c index 7565def6b27c..b505c6b49031 100644 --- a/drivers/thermal/mediatek/lvts_thermal.c +++ b/drivers/thermal/mediatek/lvts_thermal.c @@ -80,6 +80,7 @@ #define LVTS_MSR_FILTERED_MODE 1 #define LVTS_HW_SHUTDOWN_MT8195 105000 +#define LVTS_HW_SHUTDOWN_MT8192 105000 static int golden_temp = LVTS_GOLDEN_TEMP_DEFAULT; static int coeff_b = LVTS_COEFF_B; @@ -528,7 +529,7 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * The efuse blob values follows the sensor enumeration per thermal * controller. The decoding of the stream is as follow: * - * stream index map for MCU Domain : + * stream index map for MCU Domain mt8195/mt8192 : * * <-----mcu-tc#0-----> <-----sensor#0-----> <-----sensor#1-----> * 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 | 0x08 | 0x09 @@ -539,7 +540,7 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * <-----mcu-tc#2-----> <-----sensor#4-----> <-----sensor#5-----> <-----sensor#6-----> <-----sensor#7-----> * 0x13 | 0x14 | 0x15 | 0x16 | 0x17 | 0x18 | 0x19 | 0x1A | 0x1B | 0x1C | 0x1D | 0x1E | 0x1F | 0x20 | 0x21 * - * stream index map for AP Domain : + * stream index map for AP Domain mt8195/mt8192 : * * <-----ap--tc#0-----> <-----sensor#0-----> <-----sensor#1-----> * 0x22 | 0x23 | 0x24 | 0x25 | 0x26 | 0x27 | 0x28 | 0x29 | 0x2A @@ -547,12 +548,22 @@ static int lvts_sensor_init(struct device *dev, struct lvts_ctrl *lvts_ctrl, * <-----ap--tc#1-----> <-----sensor#2-----> <-----sensor#3-----> * 0x2B | 0x2C | 0x2D | 0x2E | 0x2F | 0x30 | 0x31 | 0x32 | 0x33 * + * stream index map for AP Domain mt8195 : + * * <-----ap--tc#2-----> <-----sensor#4-----> <-----sensor#5-----> <-----sensor#6-----> * 0x34 | 0x35 | 0x36 | 0x37 | 0x38 | 0x39 | 0x3A | 0x3B | 0x3C | 0x3D | 0x3E | 0x3F * * <-----ap--tc#3-----> <-----sensor#7-----> <-----sensor#8-----> * 0x40 | 0x41 | 0x42 | 0x43 | 0x44 | 0x45 | 0x46 | 0x47 | 0x48 * + * stream index map for AP Domain mt8192 : + * + * <-----ap--tc#2-----> <-----sensor#4-----> <-----sensor#5-----> + * 0x34 | 0x35 | 0x36 | 0x37 | 0x38 | 0x39 | 0x3A | 0x3B | 0x3C + * + * <-----ap--tc#3-----> <-----sensor#6-----> <-----sensor#7-----> <-----sensor#8-----> + * 0x3D | 0x3E | 0x3F | 0x40 | 0x41 | 0x42 | 0x43 | 0x44 | 0x45 | 0x46 | 0x47 | 0x48 + * * The data description gives the offset of the calibration data in * this bytes stream for each sensor. */ @@ -1246,6 +1257,85 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { } }; +static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { + { + .cal_offset = { 0x04, 0x07 }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_BIG_CPU0 }, + { .dt_id = MT8192_MCU_BIG_CPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x0, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x0d, 0x10 }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_BIG_CPU2 }, + { .dt_id = MT8192_MCU_BIG_CPU3 } + }, + .num_lvts_sensor = 2, + .offset = 0x100, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, + .lvts_sensor = { + { .dt_id = MT8192_MCU_LITTLE_CPU0 }, + { .dt_id = MT8192_MCU_LITTLE_CPU1 }, + { .dt_id = MT8192_MCU_LITTLE_CPU2 }, + { .dt_id = MT8192_MCU_LITTLE_CPU3 } + }, + .num_lvts_sensor = 4, + .offset = 0x200, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + } +}; + +static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { + { + .cal_offset = { 0x25, 0x28 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_VPU0 }, + { .dt_id = MT8192_AP_VPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x0, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x2e, 0x31 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_GPU0 }, + { .dt_id = MT8192_AP_GPU1 } + }, + .num_lvts_sensor = 2, + .offset = 0x100, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x37, 0x3a }, + .lvts_sensor = { + { .dt_id = MT8192_AP_INFRA }, + { .dt_id = MT8192_AP_CAM }, + }, + .num_lvts_sensor = 2, + .offset = 0x200, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + }, + { + .cal_offset = { 0x40, 0x43, 0x46 }, + .lvts_sensor = { + { .dt_id = MT8192_AP_MD0 }, + { .dt_id = MT8192_AP_MD1 }, + { .dt_id = MT8192_AP_MD2 } + }, + .num_lvts_sensor = 3, + .offset = 0x300, + .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, + } +}; + static const struct lvts_data mt8195_lvts_mcu_data = { .lvts_ctrl = mt8195_lvts_mcu_data_ctrl, .num_lvts_ctrl = ARRAY_SIZE(mt8195_lvts_mcu_data_ctrl), @@ -1256,9 +1346,21 @@ static const struct lvts_data mt8195_lvts_ap_data = { .num_lvts_ctrl = ARRAY_SIZE(mt8195_lvts_ap_data_ctrl), }; +static const struct lvts_data mt8192_lvts_mcu_data = { + .lvts_ctrl = mt8192_lvts_mcu_data_ctrl, + .num_lvts_ctrl = ARRAY_SIZE(mt8192_lvts_mcu_data_ctrl), +}; + +static const struct lvts_data mt8192_lvts_ap_data = { + .lvts_ctrl = mt8192_lvts_ap_data_ctrl, + .num_lvts_ctrl = ARRAY_SIZE(mt8192_lvts_ap_data_ctrl), +}; + static const struct of_device_id lvts_of_match[] = { { .compatible = "mediatek,mt8195-lvts-mcu", .data = &mt8195_lvts_mcu_data }, { .compatible = "mediatek,mt8195-lvts-ap", .data = &mt8195_lvts_ap_data }, + { .compatible = "mediatek,mt8192-lvts-mcu", .data = &mt8192_lvts_mcu_data }, + { .compatible = "mediatek,mt8192-lvts-ap", .data = &mt8192_lvts_ap_data }, {}, }; MODULE_DEVICE_TABLE(of, lvts_of_match); -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support 2023-03-07 16:34 ` bchihi @ 2023-03-08 9:23 ` AngeloGioacchino Del Regno -1 siblings, 0 replies; 46+ messages in thread From: AngeloGioacchino Del Regno @ 2023-03-08 9:23 UTC (permalink / raw) To: bchihi, daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS Driver support for MT8192. > Since you're changing that documentation twice now, you should split the doc changes in a different commit: you will see the big picture if you send just one series that introduces both MT8195-AP and MT8192 LVTS support. You don't need two series for that anyway, so... please send both the new MT8195 AP and MT8192 in a single series. Thanks, Angelo ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support @ 2023-03-08 9:23 ` AngeloGioacchino Del Regno 0 siblings, 0 replies; 46+ messages in thread From: AngeloGioacchino Del Regno @ 2023-03-08 9:23 UTC (permalink / raw) To: bchihi, daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > From: Balsam CHIHI <bchihi@baylibre.com> > > Add LVTS Driver support for MT8192. > Since you're changing that documentation twice now, you should split the doc changes in a different commit: you will see the big picture if you send just one series that introduces both MT8195-AP and MT8192 LVTS support. You don't need two series for that anyway, so... please send both the new MT8195 AP and MT8192 in a single series. Thanks, Angelo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support 2023-03-08 9:23 ` AngeloGioacchino Del Regno @ 2023-03-08 15:59 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-08 15:59 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 8, 2023 at 10:23 AM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > > From: Balsam CHIHI <bchihi@baylibre.com> > > > > Add LVTS Driver support for MT8192. > > > > Since you're changing that documentation twice now, you should split the > doc changes in a different commit: you will see the big picture if you > send just one series that introduces both MT8195-AP and MT8192 LVTS support. > > You don't need two series for that anyway, so... please send both the new > MT8195 AP and MT8192 in a single series. Hi Angelo, OK, I will send another series that contains all changes. Thank you for the review! Best regards, Balsam > > Thanks, > Angelo > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support @ 2023-03-08 15:59 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-08 15:59 UTC (permalink / raw) To: AngeloGioacchino Del Regno Cc: daniel.lezcano, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 8, 2023 at 10:23 AM AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> wrote: > > Il 07/03/23 17:34, bchihi@baylibre.com ha scritto: > > From: Balsam CHIHI <bchihi@baylibre.com> > > > > Add LVTS Driver support for MT8192. > > > > Since you're changing that documentation twice now, you should split the > doc changes in a different commit: you will see the big picture if you > send just one series that introduces both MT8195-AP and MT8192 LVTS support. > > You don't need two series for that anyway, so... please send both the new > MT8195 AP and MT8192 in a single series. Hi Angelo, OK, I will send another series that contains all changes. Thank you for the review! Best regards, Balsam > > Thanks, > Angelo > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* [PATCH 3/4] arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes 2023-03-07 16:34 ` bchihi @ 2023-03-07 16:34 ` bchihi -1 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add thermal zones and thermal nodes for the mt8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 263 +++++++++++++++++++++++ 1 file changed, 263 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 424fc89cc6f7..45c3d65a118a 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -14,6 +14,7 @@ #include <dt-bindings/phy/phy.h> #include <dt-bindings/power/mt8192-power.h> #include <dt-bindings/reset/mt8192-resets.h> +#include <dt-bindings/thermal/mediatek,lvts-thermal.h> / { compatible = "mediatek,mt8192"; @@ -620,6 +621,17 @@ spi0: spi@1100a000 { status = "disabled"; }; + lvts_ap: thermal-sensor@1100b000 { + compatible = "mediatek,mt8192-lvts-ap"; + reg = <0 0x1100b000 0 0x1000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&infracfg CLK_INFRA_THERM>; + resets = <&infracfg MT8192_INFRA_RST0_THERM_CTRL_SWRST>; + nvmem-cells = <&lvts_e_data1>; + nvmem-cell-names = "lvts-calib-data-1"; + #thermal-sensor-cells = <1>; + }; + pwm0: pwm@1100e000 { compatible = "mediatek,mt8183-disp-pwm"; reg = <0 0x1100e000 0 0x1000>; @@ -946,6 +958,17 @@ nor_flash: spi@11234000 { status = "disabled"; }; + lvts_mcu: thermal-sensor@11278000 { + compatible = "mediatek,mt8192-lvts-mcu"; + reg = <0 0x11278000 0 0x1000>; + interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&infracfg CLK_INFRA_THERM>; + resets = <&infracfg MT8192_INFRA_RST4_THERM_CTRL_MCU_SWRST>; + nvmem-cells = <&lvts_e_data1>; + nvmem-cell-names = "lvts-calib-data-1"; + #thermal-sensor-cells = <1>; + }; + efuse: efuse@11c10000 { compatible = "mediatek,mt8192-efuse", "mediatek,efuse"; reg = <0 0x11c10000 0 0x1000>; @@ -1650,4 +1673,244 @@ larb2: larb@1f002000 { power-domains = <&spm MT8192_POWER_DOMAIN_MDP>; }; }; + + thermal_zones: thermal-zones { + cpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>; + + trips { + cpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>; + + trips { + cpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu2-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>; + + trips { + cpu2_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu3-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>; + + trips { + cpu3_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu4-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>; + + trips { + cpu4_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu5-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>; + + trips { + cpu5_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu6-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>; + + trips { + cpu6_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu7-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>; + + trips { + cpu7_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + vpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_VPU0>; + + trips { + vpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + vpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_VPU1>; + + trips { + vpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + gpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_GPU0>; + + trips { + gpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + gpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_GPU1>; + + trips { + gpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + infra-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_INFRA>; + + trips { + infra_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cam-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_CAM>; + + trips { + cam_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD0>; + + trips { + md0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD1>; + + trips { + md1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md2-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD2>; + + trips { + md2_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + }; }; -- 2.34.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 3/4] arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> Add thermal zones and thermal nodes for the mt8192. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 263 +++++++++++++++++++++++ 1 file changed, 263 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 424fc89cc6f7..45c3d65a118a 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -14,6 +14,7 @@ #include <dt-bindings/phy/phy.h> #include <dt-bindings/power/mt8192-power.h> #include <dt-bindings/reset/mt8192-resets.h> +#include <dt-bindings/thermal/mediatek,lvts-thermal.h> / { compatible = "mediatek,mt8192"; @@ -620,6 +621,17 @@ spi0: spi@1100a000 { status = "disabled"; }; + lvts_ap: thermal-sensor@1100b000 { + compatible = "mediatek,mt8192-lvts-ap"; + reg = <0 0x1100b000 0 0x1000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&infracfg CLK_INFRA_THERM>; + resets = <&infracfg MT8192_INFRA_RST0_THERM_CTRL_SWRST>; + nvmem-cells = <&lvts_e_data1>; + nvmem-cell-names = "lvts-calib-data-1"; + #thermal-sensor-cells = <1>; + }; + pwm0: pwm@1100e000 { compatible = "mediatek,mt8183-disp-pwm"; reg = <0 0x1100e000 0 0x1000>; @@ -946,6 +958,17 @@ nor_flash: spi@11234000 { status = "disabled"; }; + lvts_mcu: thermal-sensor@11278000 { + compatible = "mediatek,mt8192-lvts-mcu"; + reg = <0 0x11278000 0 0x1000>; + interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&infracfg CLK_INFRA_THERM>; + resets = <&infracfg MT8192_INFRA_RST4_THERM_CTRL_MCU_SWRST>; + nvmem-cells = <&lvts_e_data1>; + nvmem-cell-names = "lvts-calib-data-1"; + #thermal-sensor-cells = <1>; + }; + efuse: efuse@11c10000 { compatible = "mediatek,mt8192-efuse", "mediatek,efuse"; reg = <0 0x11c10000 0 0x1000>; @@ -1650,4 +1673,244 @@ larb2: larb@1f002000 { power-domains = <&spm MT8192_POWER_DOMAIN_MDP>; }; }; + + thermal_zones: thermal-zones { + cpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>; + + trips { + cpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>; + + trips { + cpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu2-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>; + + trips { + cpu2_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu3-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>; + + trips { + cpu3_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu4-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>; + + trips { + cpu4_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu5-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>; + + trips { + cpu5_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu6-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>; + + trips { + cpu6_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cpu7-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>; + + trips { + cpu7_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + vpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_VPU0>; + + trips { + vpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + vpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_VPU1>; + + trips { + vpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + gpu0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_GPU0>; + + trips { + gpu0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + gpu1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_GPU1>; + + trips { + gpu1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + infra-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_INFRA>; + + trips { + infra_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + cam-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_CAM>; + + trips { + cam_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md0-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD0>; + + trips { + md0_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md1-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD1>; + + trips { + md1_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + + md2-thermal { + polling-delay = <0>; + polling-delay-passive = <0>; + thermal-sensors = <&lvts_ap MT8192_AP_MD2>; + + trips { + md2_crit: trip-crit { + temperature = <100000>; + hysteresis = <2000>; + type = "critical"; + }; + }; + }; + }; }; -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 4/4] arm64: dts: mediatek: mt8192: Add temperature mitigation threshold 2023-03-07 16:34 ` bchihi @ 2023-03-07 16:34 ` bchihi -1 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> The mt8192 SoC has several hotspots around the CPUs. Specify the targeted temperature threshold when to apply the mitigation and define the associated cooling devices. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 259 ++++++++++++++++++++--- 1 file changed, 225 insertions(+), 34 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 45c3d65a118a..772b9229b2a9 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -14,6 +14,7 @@ #include <dt-bindings/phy/phy.h> #include <dt-bindings/power/mt8192-power.h> #include <dt-bindings/reset/mt8192-resets.h> +#include <dt-bindings/thermal/thermal.h> #include <dt-bindings/thermal/mediatek,lvts-thermal.h> / { @@ -57,6 +58,7 @@ cpu0: cpu@0 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu1: cpu@100 { @@ -68,6 +70,7 @@ cpu1: cpu@100 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu2: cpu@200 { @@ -79,6 +82,7 @@ cpu2: cpu@200 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu3: cpu@300 { @@ -90,6 +94,7 @@ cpu3: cpu@300 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu4: cpu@400 { @@ -101,6 +106,7 @@ cpu4: cpu@400 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu5: cpu@500 { @@ -112,6 +118,7 @@ cpu5: cpu@500 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu6: cpu@600 { @@ -123,6 +130,7 @@ cpu6: cpu@600 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu7: cpu@700 { @@ -134,6 +142,7 @@ cpu7: cpu@700 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu-map { @@ -1676,123 +1685,257 @@ larb2: larb@1f002000 { thermal_zones: thermal-zones { cpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>; trips { + cpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu0_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>; trips { + cpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu1_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu2-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>; trips { + cpu2_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu2_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu2_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu3-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>; trips { + cpu3_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu3_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu3_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu4-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>; trips { + cpu4_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu4_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu4_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu5-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>; trips { + cpu5_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu5_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu5_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu6-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>; trips { + cpu6_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu6_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu6_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu7-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>; trips { + cpu7_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu7_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu7_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; vpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_VPU0>; trips { + vpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + vpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1802,11 +1945,17 @@ vpu0_crit: trip-crit { }; vpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_VPU1>; trips { + vpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + vpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1816,11 +1965,17 @@ vpu1_crit: trip-crit { }; gpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_GPU0>; trips { + gpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + gpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1830,11 +1985,17 @@ gpu0_crit: trip-crit { }; gpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_GPU1>; trips { + gpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + gpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1844,11 +2005,17 @@ gpu1_crit: trip-crit { }; infra-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_INFRA>; trips { + infra_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + infra_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1858,11 +2025,17 @@ infra_crit: trip-crit { }; cam-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_CAM>; trips { + cam_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cam_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1872,11 +2045,17 @@ cam_crit: trip-crit { }; md0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD0>; trips { + md0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1886,11 +2065,17 @@ md0_crit: trip-crit { }; md1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD1>; trips { + md1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1900,11 +2085,17 @@ md1_crit: trip-crit { }; md2-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD2>; trips { + md2_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md2_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; -- 2.34.1 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* [PATCH 4/4] arm64: dts: mediatek: mt8192: Add temperature mitigation threshold @ 2023-03-07 16:34 ` bchihi 0 siblings, 0 replies; 46+ messages in thread From: bchihi @ 2023-03-07 16:34 UTC (permalink / raw) To: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel Cc: linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen From: Balsam CHIHI <bchihi@baylibre.com> The mt8192 SoC has several hotspots around the CPUs. Specify the targeted temperature threshold when to apply the mitigation and define the associated cooling devices. Signed-off-by: Balsam CHIHI <bchihi@baylibre.com> --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 259 ++++++++++++++++++++--- 1 file changed, 225 insertions(+), 34 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi index 45c3d65a118a..772b9229b2a9 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -14,6 +14,7 @@ #include <dt-bindings/phy/phy.h> #include <dt-bindings/power/mt8192-power.h> #include <dt-bindings/reset/mt8192-resets.h> +#include <dt-bindings/thermal/thermal.h> #include <dt-bindings/thermal/mediatek,lvts-thermal.h> / { @@ -57,6 +58,7 @@ cpu0: cpu@0 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu1: cpu@100 { @@ -68,6 +70,7 @@ cpu1: cpu@100 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu2: cpu@200 { @@ -79,6 +82,7 @@ cpu2: cpu@200 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu3: cpu@300 { @@ -90,6 +94,7 @@ cpu3: cpu@300 { cpu-idle-states = <&cpu_sleep_l &cluster_sleep_l>; next-level-cache = <&l2_0>; capacity-dmips-mhz = <530>; + #cooling-cells = <2>; }; cpu4: cpu@400 { @@ -101,6 +106,7 @@ cpu4: cpu@400 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu5: cpu@500 { @@ -112,6 +118,7 @@ cpu5: cpu@500 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu6: cpu@600 { @@ -123,6 +130,7 @@ cpu6: cpu@600 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu7: cpu@700 { @@ -134,6 +142,7 @@ cpu7: cpu@700 { cpu-idle-states = <&cpu_sleep_b &cluster_sleep_b>; next-level-cache = <&l2_1>; capacity-dmips-mhz = <1024>; + #cooling-cells = <2>; }; cpu-map { @@ -1676,123 +1685,257 @@ larb2: larb@1f002000 { thermal_zones: thermal-zones { cpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>; trips { + cpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu0_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>; trips { + cpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu1_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu2-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>; trips { + cpu2_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu2_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu2_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu3-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>; trips { + cpu3_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu3_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu3_alert>; + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu4-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>; trips { + cpu4_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu4_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu4_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu5-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>; trips { + cpu5_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu5_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu5_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu6-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>; trips { + cpu6_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu6_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu6_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; cpu7-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>; trips { + cpu7_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cpu7_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; type = "critical"; }; }; + + cooling-maps { + map0 { + trip = <&cpu7_alert>; + cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>, + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>; + }; + }; }; vpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_VPU0>; trips { + vpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + vpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1802,11 +1945,17 @@ vpu0_crit: trip-crit { }; vpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_VPU1>; trips { + vpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + vpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1816,11 +1965,17 @@ vpu1_crit: trip-crit { }; gpu0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_GPU0>; trips { + gpu0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + gpu0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1830,11 +1985,17 @@ gpu0_crit: trip-crit { }; gpu1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_GPU1>; trips { + gpu1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + gpu1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1844,11 +2005,17 @@ gpu1_crit: trip-crit { }; infra-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_INFRA>; trips { + infra_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + infra_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1858,11 +2025,17 @@ infra_crit: trip-crit { }; cam-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_CAM>; trips { + cam_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + cam_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1872,11 +2045,17 @@ cam_crit: trip-crit { }; md0-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD0>; trips { + md0_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md0_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1886,11 +2065,17 @@ md0_crit: trip-crit { }; md1-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD1>; trips { + md1_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md1_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; @@ -1900,11 +2085,17 @@ md1_crit: trip-crit { }; md2-thermal { - polling-delay = <0>; - polling-delay-passive = <0>; + polling-delay = <1000>; + polling-delay-passive = <250>; thermal-sensors = <&lvts_ap MT8192_AP_MD2>; trips { + md2_alert: trip-alert { + temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; + md2_crit: trip-crit { temperature = <100000>; hysteresis = <2000>; -- 2.34.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-07 16:34 ` bchihi @ 2023-03-09 5:04 ` Chen-Yu Tsai -1 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-09 5:04 UTC (permalink / raw) To: bchihi Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 8, 2023 at 12:34 AM <bchihi@baylibre.com> wrote: > > From: Balsam CHIHI <bchihi@baylibre.com> > > Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. > > This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : > https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ > and "Add LVTS's AP thermal domain support for mt8195" : > https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ > > Based on top of thermal/linux-next : > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > > Depends on these patches as they are not yet applyied to thermal/linux-next branch : > [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ > [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ > > Balsam CHIHI (4): > dt-bindings: thermal: mediatek: Add LVTS thermal controller definition > for mt8192 > thermal/drivers/mediatek/lvts_thermal: Add mt8192 support > arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes > arm64: dts: mediatek: mt8192: Add temperature mitigation threshold I tried this on my Hayato. As soon as lvts_ap probes and its thermal zones are registered, a "critical temperature reached" warning is immediately triggered for all the zones, a reboot is forced. A NULL pointer dereference is also triggered somewhere. I filtered out all the interspersed "critical temperature" messages: [ 2.943847] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000600 [ 2.958818] Mem abort info: [ 2.965996] ESR = 0x0000000096000005 [ 2.973765] SMCCC: SOC_ID: ID = jep106:0426:8192 Revision = 0x00000000 [ 2.975442] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.987305] SET = 0, FnV = 0 [ 2.995521] EA = 0, S1PTW = 0 [ 3.004265] FSC = 0x05: level 1 translation fault [ 3.014365] Data abort info: [ 3.017344] ISV = 0, ISS = 0x00000005 [ 3.021279] CM = 0, WnR = 0 [ 3.022124] GACT probability NOT on [ 3.024277] [0000000000000600] user address but active_mm is swapper [ 3.034190] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 3.044738] Modules linked in: [ 3.044745] CPU: 0 PID: 97 Comm: irq/273-1100b00 Not tainted 6.3.0-rc1-next-20230308-01996-g3c0b9a61a3e5-dirty #575 c7b94096b594a95f18217c2ad4a2bd6d2c431108 [ 3.044751] Hardware name: Google Hayato rev1 (DT) [ 3.044755] pstate: 60000009 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.052055] pc : __mutex_lock+0x60/0x438 [ 3.052066] lr : __mutex_lock+0x54/0x438 [ 3.052070] sp : ffffffc008883c60 [ 3.070822] x29: ffffffc008883c60 x28: ffffff80c281a880 x27: 000881f00009001f [ 3.070830] x26: 1fc0000000247c00 x25: ffffff80c281a900 x24: 0000000000000000 [ 3.070837] x23: 0000000000000000 x22: ffffffe5ae5d45f4 x21: 0000000000000002 [ 3.086211] x20: 0000000000000000 x19: 00000000000005a0 x18: ffffffffffffffff [ 3.086218] x17: 6568636165722065 x16: 727574617265706d x15: 0000000000000028 [ 3.097773] x14: 0000000000000000 x13: 0000000000003395 x12: ffffffe5af7f6ff0 [ 3.097780] x11: 65706d655428206e x10: 0000000000000000 x9 : ffffffe5adcf4b08 [ 3.097787] x8 : ffffffe5afe03230 x7 : 00000000000261b0 x6 : ffffff80c2b86600 [ 3.105609] x5 : 0000000000000000 x4 : ffffff80c2b86600 x3 : 0000000000000000 [ 3.112565] x2 : ffffff9b505f6000 x1 : 0000000000000000 x0 : 0000000000000000 [ 3.127593] Call trace: [ 3.127595] __mutex_lock+0x60/0x438 [ 3.127600] mutex_lock_nested+0x34/0x48 [ 3.141844] thermal_zone_device_update+0x34/0x80 [ 3.152879] lvts_irq_handler+0xbc/0x158 [ 3.152886] irq_thread_fn+0x34/0xb8 [ 3.161489] irq_thread+0x19c/0x298 [ 3.161494] kthread+0x11c/0x128 [ 3.175152] ret_from_fork+0x10/0x20 [ 3.175163] Code: 97ccbb7c 9000bea0 b9411400 35000080 (f9403260) [ 3.189402] ---[ end trace 0000000000000000 ]--- [ 3.193417] Kernel panic - not syncing: Oops: Fatal exception [ 3.201255] Kernel Offset: 0x25a5c00000 from 0xffffffc008000000 [ 3.201257] PHYS_OFFSET: 0x40000000 [ 3.201259] CPU features: 0x600000,01700506,3200720b [ 3.201263] Memory Limit: none [ 3.376838] Rebooting in 30 seconds.. > arch/arm64/boot/dts/mediatek/mt8192.dtsi | 454 ++++++++++++++++++ > drivers/thermal/mediatek/lvts_thermal.c | 106 +++- > .../thermal/mediatek,lvts-thermal.h | 19 + > 3 files changed, 577 insertions(+), 2 deletions(-) > > > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > prerequisite-patch-id: 73be949bd16979769e5b94905b244dcee4a8f687 > prerequisite-patch-id: 9076e9b3bd3cc411b7b80344211364db5f0cca17 > prerequisite-patch-id: e220d6ae26786f524c249588433f02e5f5f906ad > prerequisite-patch-id: 58e295ae36ad4784f3eb3830412f35dad31bb8b6 > prerequisite-patch-id: d23d83a946e5b876ef01a717fd51b07df1fa08dd > prerequisite-patch-id: d67f2455eef1c4a9ecc460dbf3c2e3ad47d213ec > prerequisite-patch-id: b407d2998e57678952128b3a4bac92a379132b09 > prerequisite-patch-id: fbb9212ce8c3530da17d213f56fa334ce4fa1b2b > prerequisite-patch-id: 5db9eed2659028cf4419f2de3d093af7df6c2dad > prerequisite-patch-id: a83c00c628605d1c8fbe1d97074f9f28efb1bcfc > -- > 2.34.1 > > ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-09 5:04 ` Chen-Yu Tsai 0 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-09 5:04 UTC (permalink / raw) To: bchihi Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 8, 2023 at 12:34 AM <bchihi@baylibre.com> wrote: > > From: Balsam CHIHI <bchihi@baylibre.com> > > Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. > > This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : > https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ > and "Add LVTS's AP thermal domain support for mt8195" : > https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ > > Based on top of thermal/linux-next : > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > > Depends on these patches as they are not yet applyied to thermal/linux-next branch : > [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ > [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ > > Balsam CHIHI (4): > dt-bindings: thermal: mediatek: Add LVTS thermal controller definition > for mt8192 > thermal/drivers/mediatek/lvts_thermal: Add mt8192 support > arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes > arm64: dts: mediatek: mt8192: Add temperature mitigation threshold I tried this on my Hayato. As soon as lvts_ap probes and its thermal zones are registered, a "critical temperature reached" warning is immediately triggered for all the zones, a reboot is forced. A NULL pointer dereference is also triggered somewhere. I filtered out all the interspersed "critical temperature" messages: [ 2.943847] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000600 [ 2.958818] Mem abort info: [ 2.965996] ESR = 0x0000000096000005 [ 2.973765] SMCCC: SOC_ID: ID = jep106:0426:8192 Revision = 0x00000000 [ 2.975442] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.987305] SET = 0, FnV = 0 [ 2.995521] EA = 0, S1PTW = 0 [ 3.004265] FSC = 0x05: level 1 translation fault [ 3.014365] Data abort info: [ 3.017344] ISV = 0, ISS = 0x00000005 [ 3.021279] CM = 0, WnR = 0 [ 3.022124] GACT probability NOT on [ 3.024277] [0000000000000600] user address but active_mm is swapper [ 3.034190] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 3.044738] Modules linked in: [ 3.044745] CPU: 0 PID: 97 Comm: irq/273-1100b00 Not tainted 6.3.0-rc1-next-20230308-01996-g3c0b9a61a3e5-dirty #575 c7b94096b594a95f18217c2ad4a2bd6d2c431108 [ 3.044751] Hardware name: Google Hayato rev1 (DT) [ 3.044755] pstate: 60000009 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 3.052055] pc : __mutex_lock+0x60/0x438 [ 3.052066] lr : __mutex_lock+0x54/0x438 [ 3.052070] sp : ffffffc008883c60 [ 3.070822] x29: ffffffc008883c60 x28: ffffff80c281a880 x27: 000881f00009001f [ 3.070830] x26: 1fc0000000247c00 x25: ffffff80c281a900 x24: 0000000000000000 [ 3.070837] x23: 0000000000000000 x22: ffffffe5ae5d45f4 x21: 0000000000000002 [ 3.086211] x20: 0000000000000000 x19: 00000000000005a0 x18: ffffffffffffffff [ 3.086218] x17: 6568636165722065 x16: 727574617265706d x15: 0000000000000028 [ 3.097773] x14: 0000000000000000 x13: 0000000000003395 x12: ffffffe5af7f6ff0 [ 3.097780] x11: 65706d655428206e x10: 0000000000000000 x9 : ffffffe5adcf4b08 [ 3.097787] x8 : ffffffe5afe03230 x7 : 00000000000261b0 x6 : ffffff80c2b86600 [ 3.105609] x5 : 0000000000000000 x4 : ffffff80c2b86600 x3 : 0000000000000000 [ 3.112565] x2 : ffffff9b505f6000 x1 : 0000000000000000 x0 : 0000000000000000 [ 3.127593] Call trace: [ 3.127595] __mutex_lock+0x60/0x438 [ 3.127600] mutex_lock_nested+0x34/0x48 [ 3.141844] thermal_zone_device_update+0x34/0x80 [ 3.152879] lvts_irq_handler+0xbc/0x158 [ 3.152886] irq_thread_fn+0x34/0xb8 [ 3.161489] irq_thread+0x19c/0x298 [ 3.161494] kthread+0x11c/0x128 [ 3.175152] ret_from_fork+0x10/0x20 [ 3.175163] Code: 97ccbb7c 9000bea0 b9411400 35000080 (f9403260) [ 3.189402] ---[ end trace 0000000000000000 ]--- [ 3.193417] Kernel panic - not syncing: Oops: Fatal exception [ 3.201255] Kernel Offset: 0x25a5c00000 from 0xffffffc008000000 [ 3.201257] PHYS_OFFSET: 0x40000000 [ 3.201259] CPU features: 0x600000,01700506,3200720b [ 3.201263] Memory Limit: none [ 3.376838] Rebooting in 30 seconds.. > arch/arm64/boot/dts/mediatek/mt8192.dtsi | 454 ++++++++++++++++++ > drivers/thermal/mediatek/lvts_thermal.c | 106 +++- > .../thermal/mediatek,lvts-thermal.h | 19 + > 3 files changed, 577 insertions(+), 2 deletions(-) > > > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > prerequisite-patch-id: 73be949bd16979769e5b94905b244dcee4a8f687 > prerequisite-patch-id: 9076e9b3bd3cc411b7b80344211364db5f0cca17 > prerequisite-patch-id: e220d6ae26786f524c249588433f02e5f5f906ad > prerequisite-patch-id: 58e295ae36ad4784f3eb3830412f35dad31bb8b6 > prerequisite-patch-id: d23d83a946e5b876ef01a717fd51b07df1fa08dd > prerequisite-patch-id: d67f2455eef1c4a9ecc460dbf3c2e3ad47d213ec > prerequisite-patch-id: b407d2998e57678952128b3a4bac92a379132b09 > prerequisite-patch-id: fbb9212ce8c3530da17d213f56fa334ce4fa1b2b > prerequisite-patch-id: 5db9eed2659028cf4419f2de3d093af7df6c2dad > prerequisite-patch-id: a83c00c628605d1c8fbe1d97074f9f28efb1bcfc > -- > 2.34.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-09 5:04 ` Chen-Yu Tsai @ 2023-03-09 10:47 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-09 10:47 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, On Thu, Mar 9, 2023 at 6:04 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Wed, Mar 8, 2023 at 12:34 AM <bchihi@baylibre.com> wrote: > > > > From: Balsam CHIHI <bchihi@baylibre.com> > > > > Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. > > > > This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : > > https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ > > and "Add LVTS's AP thermal domain support for mt8195" : > > https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ > > > > Based on top of thermal/linux-next : > > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > > > > Depends on these patches as they are not yet applyied to thermal/linux-next branch : > > [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 > > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ > > [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 > > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ > > > > Balsam CHIHI (4): > > dt-bindings: thermal: mediatek: Add LVTS thermal controller definition > > for mt8192 > > thermal/drivers/mediatek/lvts_thermal: Add mt8192 support > > arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes > > arm64: dts: mediatek: mt8192: Add temperature mitigation threshold > > I tried this on my Hayato. As soon as lvts_ap probes and its thermal zones > are registered, a "critical temperature reached" warning is immediately > triggered for all the zones, a reboot is forced. A NULL pointer dereference > is also triggered somewhere. I filtered out all the interspersed "critical > temperature" messages: > Thank you very much for testing! It seems like interrupts on mt8192 and mt8195 do not behave the same way. I am investigating the issues. > [ 2.943847] Unable to handle kernel NULL pointer dereference at > virtual address 0000000000000600 > [ 2.958818] Mem abort info: > [ 2.965996] ESR = 0x0000000096000005 > [ 2.973765] SMCCC: SOC_ID: ID = jep106:0426:8192 Revision = 0x00000000 > [ 2.975442] EC = 0x25: DABT (current EL), IL = 32 bits > [ 2.987305] SET = 0, FnV = 0 > [ 2.995521] EA = 0, S1PTW = 0 > [ 3.004265] FSC = 0x05: level 1 translation fault > [ 3.014365] Data abort info: > [ 3.017344] ISV = 0, ISS = 0x00000005 > [ 3.021279] CM = 0, WnR = 0 > [ 3.022124] GACT probability NOT on > [ 3.024277] [0000000000000600] user address but active_mm is swapper > [ 3.034190] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP > [ 3.044738] Modules linked in: > [ 3.044745] CPU: 0 PID: 97 Comm: irq/273-1100b00 Not tainted > 6.3.0-rc1-next-20230308-01996-g3c0b9a61a3e5-dirty #575 > c7b94096b594a95f18217c2ad4a2bd6d2c431108 > [ 3.044751] Hardware name: Google Hayato rev1 (DT) > [ 3.044755] pstate: 60000009 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 3.052055] pc : __mutex_lock+0x60/0x438 > [ 3.052066] lr : __mutex_lock+0x54/0x438 > [ 3.052070] sp : ffffffc008883c60 > [ 3.070822] x29: ffffffc008883c60 x28: ffffff80c281a880 x27: 000881f00009001f > [ 3.070830] x26: 1fc0000000247c00 x25: ffffff80c281a900 x24: 0000000000000000 > [ 3.070837] x23: 0000000000000000 x22: ffffffe5ae5d45f4 x21: 0000000000000002 > [ 3.086211] x20: 0000000000000000 x19: 00000000000005a0 x18: ffffffffffffffff > [ 3.086218] x17: 6568636165722065 x16: 727574617265706d x15: 0000000000000028 > [ 3.097773] x14: 0000000000000000 x13: 0000000000003395 x12: ffffffe5af7f6ff0 > [ 3.097780] x11: 65706d655428206e x10: 0000000000000000 x9 : ffffffe5adcf4b08 > [ 3.097787] x8 : ffffffe5afe03230 x7 : 00000000000261b0 x6 : ffffff80c2b86600 > [ 3.105609] x5 : 0000000000000000 x4 : ffffff80c2b86600 x3 : 0000000000000000 > [ 3.112565] x2 : ffffff9b505f6000 x1 : 0000000000000000 x0 : 0000000000000000 > [ 3.127593] Call trace: > [ 3.127595] __mutex_lock+0x60/0x438 > [ 3.127600] mutex_lock_nested+0x34/0x48 > [ 3.141844] thermal_zone_device_update+0x34/0x80 > [ 3.152879] lvts_irq_handler+0xbc/0x158 > [ 3.152886] irq_thread_fn+0x34/0xb8 > [ 3.161489] irq_thread+0x19c/0x298 > [ 3.161494] kthread+0x11c/0x128 > [ 3.175152] ret_from_fork+0x10/0x20 > [ 3.175163] Code: 97ccbb7c 9000bea0 b9411400 35000080 (f9403260) > [ 3.189402] ---[ end trace 0000000000000000 ]--- > [ 3.193417] Kernel panic - not syncing: Oops: Fatal exception > [ 3.201255] Kernel Offset: 0x25a5c00000 from 0xffffffc008000000 > [ 3.201257] PHYS_OFFSET: 0x40000000 > [ 3.201259] CPU features: 0x600000,01700506,3200720b > [ 3.201263] Memory Limit: none > [ 3.376838] Rebooting in 30 seconds.. > > [...] Best regards, Balsam ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-09 10:47 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-09 10:47 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, On Thu, Mar 9, 2023 at 6:04 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Wed, Mar 8, 2023 at 12:34 AM <bchihi@baylibre.com> wrote: > > > > From: Balsam CHIHI <bchihi@baylibre.com> > > > > Add full LVTS support (MCU thermal domain + AP thermal domain) to MediaTek MT8192 SoC. > > > > This series is a continuation of the previous series "Add LVTS Thermal Architecture" v14 : > > https://patchwork.kernel.org/project/linux-pm/cover/20230209105628.50294-1-bchihi@baylibre.com/ > > and "Add LVTS's AP thermal domain support for mt8195" : > > https://patchwork.kernel.org/project/linux-pm/cover/20230307154524.118541-1-bchihi@baylibre.com/ > > > > Based on top of thermal/linux-next : > > base-commit: 6828e402d06f7c574430b61c05db784cd847b19f > > > > Depends on these patches as they are not yet applyied to thermal/linux-next branch : > > [1/4] dt-bindings: thermal: mediatek: Add AP domain to LVTS thermal controllers for mt8195 > > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-2-bchihi@baylibre.com/ > > [2/4] thermal/drivers/mediatek/lvts_thermal: Add AP domain for mt8195 > > https://patchwork.kernel.org/project/linux-pm/patch/20230307154524.118541-3-bchihi@baylibre.com/ > > > > Balsam CHIHI (4): > > dt-bindings: thermal: mediatek: Add LVTS thermal controller definition > > for mt8192 > > thermal/drivers/mediatek/lvts_thermal: Add mt8192 support > > arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes > > arm64: dts: mediatek: mt8192: Add temperature mitigation threshold > > I tried this on my Hayato. As soon as lvts_ap probes and its thermal zones > are registered, a "critical temperature reached" warning is immediately > triggered for all the zones, a reboot is forced. A NULL pointer dereference > is also triggered somewhere. I filtered out all the interspersed "critical > temperature" messages: > Thank you very much for testing! It seems like interrupts on mt8192 and mt8195 do not behave the same way. I am investigating the issues. > [ 2.943847] Unable to handle kernel NULL pointer dereference at > virtual address 0000000000000600 > [ 2.958818] Mem abort info: > [ 2.965996] ESR = 0x0000000096000005 > [ 2.973765] SMCCC: SOC_ID: ID = jep106:0426:8192 Revision = 0x00000000 > [ 2.975442] EC = 0x25: DABT (current EL), IL = 32 bits > [ 2.987305] SET = 0, FnV = 0 > [ 2.995521] EA = 0, S1PTW = 0 > [ 3.004265] FSC = 0x05: level 1 translation fault > [ 3.014365] Data abort info: > [ 3.017344] ISV = 0, ISS = 0x00000005 > [ 3.021279] CM = 0, WnR = 0 > [ 3.022124] GACT probability NOT on > [ 3.024277] [0000000000000600] user address but active_mm is swapper > [ 3.034190] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP > [ 3.044738] Modules linked in: > [ 3.044745] CPU: 0 PID: 97 Comm: irq/273-1100b00 Not tainted > 6.3.0-rc1-next-20230308-01996-g3c0b9a61a3e5-dirty #575 > c7b94096b594a95f18217c2ad4a2bd6d2c431108 > [ 3.044751] Hardware name: Google Hayato rev1 (DT) > [ 3.044755] pstate: 60000009 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) > [ 3.052055] pc : __mutex_lock+0x60/0x438 > [ 3.052066] lr : __mutex_lock+0x54/0x438 > [ 3.052070] sp : ffffffc008883c60 > [ 3.070822] x29: ffffffc008883c60 x28: ffffff80c281a880 x27: 000881f00009001f > [ 3.070830] x26: 1fc0000000247c00 x25: ffffff80c281a900 x24: 0000000000000000 > [ 3.070837] x23: 0000000000000000 x22: ffffffe5ae5d45f4 x21: 0000000000000002 > [ 3.086211] x20: 0000000000000000 x19: 00000000000005a0 x18: ffffffffffffffff > [ 3.086218] x17: 6568636165722065 x16: 727574617265706d x15: 0000000000000028 > [ 3.097773] x14: 0000000000000000 x13: 0000000000003395 x12: ffffffe5af7f6ff0 > [ 3.097780] x11: 65706d655428206e x10: 0000000000000000 x9 : ffffffe5adcf4b08 > [ 3.097787] x8 : ffffffe5afe03230 x7 : 00000000000261b0 x6 : ffffff80c2b86600 > [ 3.105609] x5 : 0000000000000000 x4 : ffffff80c2b86600 x3 : 0000000000000000 > [ 3.112565] x2 : ffffff9b505f6000 x1 : 0000000000000000 x0 : 0000000000000000 > [ 3.127593] Call trace: > [ 3.127595] __mutex_lock+0x60/0x438 > [ 3.127600] mutex_lock_nested+0x34/0x48 > [ 3.141844] thermal_zone_device_update+0x34/0x80 > [ 3.152879] lvts_irq_handler+0xbc/0x158 > [ 3.152886] irq_thread_fn+0x34/0xb8 > [ 3.161489] irq_thread+0x19c/0x298 > [ 3.161494] kthread+0x11c/0x128 > [ 3.175152] ret_from_fork+0x10/0x20 > [ 3.175163] Code: 97ccbb7c 9000bea0 b9411400 35000080 (f9403260) > [ 3.189402] ---[ end trace 0000000000000000 ]--- > [ 3.193417] Kernel panic - not syncing: Oops: Fatal exception > [ 3.201255] Kernel Offset: 0x25a5c00000 from 0xffffffc008000000 > [ 3.201257] PHYS_OFFSET: 0x40000000 > [ 3.201259] CPU features: 0x600000,01700506,3200720b > [ 3.201263] Memory Limit: none > [ 3.376838] Rebooting in 30 seconds.. > > [...] Best regards, Balsam _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-09 10:47 ` Balsam CHIHI @ 2023-03-22 12:48 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-22 12:48 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, I suspect the bug comes from incorrect calibration data offsets for AP Domain because you confirm that MCU Domain probe runs without issues. Is it possible to test something for us to confirm this theory (i don't have an mt8192 board on hand now), when you have the time of course? We would like to test AP Domain's calibration data offsets with a working one, for example : static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { { - .cal_offset = { 0x25, 0x28 }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_VPU0 }, { .dt_id = MT8192_AP_VPU1 } @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x2e, 0x31 }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_GPU0 }, { .dt_id = MT8192_AP_GPU1 } @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x37, 0x3a }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_INFRA }, { .dt_id = MT8192_AP_CAM }, @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x40, 0x43, 0x46 }, + .cal_offset = { 0x04, 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_MD0 }, { .dt_id = MT8192_AP_MD1 }, This example is tested and works for mt8195, (all sensors use the same calibration data offset for testing purposes). Thank you in advance for your help. Best regards, Balsam ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-22 12:48 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-22 12:48 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, I suspect the bug comes from incorrect calibration data offsets for AP Domain because you confirm that MCU Domain probe runs without issues. Is it possible to test something for us to confirm this theory (i don't have an mt8192 board on hand now), when you have the time of course? We would like to test AP Domain's calibration data offsets with a working one, for example : static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { { - .cal_offset = { 0x25, 0x28 }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_VPU0 }, { .dt_id = MT8192_AP_VPU1 } @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x2e, 0x31 }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_GPU0 }, { .dt_id = MT8192_AP_GPU1 } @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x37, 0x3a }, + .cal_offset = { 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_INFRA }, { .dt_id = MT8192_AP_CAM }, @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x40, 0x43, 0x46 }, + .cal_offset = { 0x04, 0x04, 0x04 }, .lvts_sensor = { { .dt_id = MT8192_AP_MD0 }, { .dt_id = MT8192_AP_MD1 }, This example is tested and works for mt8195, (all sensors use the same calibration data offset for testing purposes). Thank you in advance for your help. Best regards, Balsam _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-22 12:48 ` Balsam CHIHI @ 2023-03-25 4:33 ` Chen-Yu Tsai -1 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-25 4:33 UTC (permalink / raw) To: Balsam CHIHI Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > Hi Chen-Yu, > > I suspect the bug comes from incorrect calibration data offsets for AP > Domain because you confirm that MCU Domain probe runs without issues. > Is it possible to test something for us to confirm this theory (i > don't have an mt8192 board on hand now), when you have the time of > course? > We would like to test AP Domain's calibration data offsets with a > working one, for example : > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x04, 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > > This example is tested and works for mt8195, > (all sensors use the same calibration data offset for testing purposes). > > Thank you in advance for your help. The MCU ones are still tripping though. If I change all of them to 0x04, then nothing trips. There's also a bug in the interrupt handling code that needs to be dealt with. AFAICT the calibration data is stored differently. If you look at ChromeOS's downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: MT8195 has all data sequentially stored, while MT8192 has most data stored in lower 24 bits of each 32-bit word, and the highest 8 bits are then used to pack data for the remaining sensors. Regards ChenYu ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-25 4:33 ` Chen-Yu Tsai 0 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-25 4:33 UTC (permalink / raw) To: Balsam CHIHI Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > Hi Chen-Yu, > > I suspect the bug comes from incorrect calibration data offsets for AP > Domain because you confirm that MCU Domain probe runs without issues. > Is it possible to test something for us to confirm this theory (i > don't have an mt8192 board on hand now), when you have the time of > course? > We would like to test AP Domain's calibration data offsets with a > working one, for example : > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x04, 0x04, 0x04 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > > This example is tested and works for mt8195, > (all sensors use the same calibration data offset for testing purposes). > > Thank you in advance for your help. The MCU ones are still tripping though. If I change all of them to 0x04, then nothing trips. There's also a bug in the interrupt handling code that needs to be dealt with. AFAICT the calibration data is stored differently. If you look at ChromeOS's downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: MT8195 has all data sequentially stored, while MT8192 has most data stored in lower 24 bits of each 32-bit word, and the highest 8 bits are then used to pack data for the remaining sensors. Regards ChenYu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-25 4:33 ` Chen-Yu Tsai @ 2023-03-28 0:20 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-28 0:20 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > Hi Chen-Yu, > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > Domain because you confirm that MCU Domain probe runs without issues. > > Is it possible to test something for us to confirm this theory (i > > don't have an mt8192 board on hand now), when you have the time of > > course? > > We would like to test AP Domain's calibration data offsets with a > > working one, for example : > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > { > > - .cal_offset = { 0x25, 0x28 }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_VPU0 }, > > { .dt_id = MT8192_AP_VPU1 } > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x2e, 0x31 }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_GPU0 }, > > { .dt_id = MT8192_AP_GPU1 } > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x37, 0x3a }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_INFRA }, > > { .dt_id = MT8192_AP_CAM }, > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_MD0 }, > > { .dt_id = MT8192_AP_MD1 }, > > > > This example is tested and works for mt8195, > > (all sensors use the same calibration data offset for testing purposes). > > > > Thank you in advance for your help. > > The MCU ones are still tripping though. If I change all of them to 0x04, > then nothing trips. There's also a bug in the interrupt handling code > that needs to be dealt with. > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > MT8195 has all data sequentially stored, while MT8192 has most data stored > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > to pack data for the remaining sensors. > > Regards > ChenYu Hi Chen-Yu Tsai, Thank you very much for helping me testing this suggestion. Indeed, calibration data is stored differently in the mt8192 compared to mt8195. So, the mt8192's support will be delayed for now, to allow further debugging. In the mean time, we will only continue to upstream the remaining mt8195's source code, so it will get full LVTS support. A new series will be submitted soon. Would you please point me out to the bug in interrupt handling code? Best regards, Balsam ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-28 0:20 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-28 0:20 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > Hi Chen-Yu, > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > Domain because you confirm that MCU Domain probe runs without issues. > > Is it possible to test something for us to confirm this theory (i > > don't have an mt8192 board on hand now), when you have the time of > > course? > > We would like to test AP Domain's calibration data offsets with a > > working one, for example : > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > { > > - .cal_offset = { 0x25, 0x28 }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_VPU0 }, > > { .dt_id = MT8192_AP_VPU1 } > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x2e, 0x31 }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_GPU0 }, > > { .dt_id = MT8192_AP_GPU1 } > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x37, 0x3a }, > > + .cal_offset = { 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_INFRA }, > > { .dt_id = MT8192_AP_CAM }, > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_MD0 }, > > { .dt_id = MT8192_AP_MD1 }, > > > > This example is tested and works for mt8195, > > (all sensors use the same calibration data offset for testing purposes). > > > > Thank you in advance for your help. > > The MCU ones are still tripping though. If I change all of them to 0x04, > then nothing trips. There's also a bug in the interrupt handling code > that needs to be dealt with. > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > MT8195 has all data sequentially stored, while MT8192 has most data stored > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > to pack data for the remaining sensors. > > Regards > ChenYu Hi Chen-Yu Tsai, Thank you very much for helping me testing this suggestion. Indeed, calibration data is stored differently in the mt8192 compared to mt8195. So, the mt8192's support will be delayed for now, to allow further debugging. In the mean time, we will only continue to upstream the remaining mt8195's source code, so it will get full LVTS support. A new series will be submitted soon. Would you please point me out to the bug in interrupt handling code? Best regards, Balsam _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-28 0:20 ` Balsam CHIHI @ 2023-03-28 3:12 ` Chen-Yu Tsai -1 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-28 3:12 UTC (permalink / raw) To: Balsam CHIHI Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Mar 28, 2023 at 8:21 AM Balsam CHIHI <bchihi@baylibre.com> wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > Hi Chen-Yu, > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > Domain because you confirm that MCU Domain probe runs without issues. > > > Is it possible to test something for us to confirm this theory (i > > > don't have an mt8192 board on hand now), when you have the time of > > > course? > > > We would like to test AP Domain's calibration data offsets with a > > > working one, for example : > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > { > > > - .cal_offset = { 0x25, 0x28 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_VPU0 }, > > > { .dt_id = MT8192_AP_VPU1 } > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x2e, 0x31 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_GPU0 }, > > > { .dt_id = MT8192_AP_GPU1 } > > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x37, 0x3a }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_INFRA }, > > > { .dt_id = MT8192_AP_CAM }, > > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_MD0 }, > > > { .dt_id = MT8192_AP_MD1 }, > > > > > > This example is tested and works for mt8195, > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > Thank you in advance for your help. > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > then nothing trips. There's also a bug in the interrupt handling code > > that needs to be dealt with. > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > to pack data for the remaining sensors. > > > > Regards > > ChenYu > > Hi Chen-Yu Tsai, > > Thank you very much for helping me testing this suggestion. > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > So, the mt8192's support will be delayed for now, to allow further debugging. > > In the mean time, we will only continue to upstream the remaining > mt8195's source code, so it will get full LVTS support. > A new series will be submitted soon. > > Would you please point me out to the bug in interrupt handling code? I just sent out two patches and CC-ed you on them. They are here just in case: https://lore.kernel.org/linux-pm/20230328031037.1361048-1-wenst@chromium.org/ https://lore.kernel.org/linux-pm/20230328031017.1360976-1-wenst@chromium.org/ ChenYu ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-28 3:12 ` Chen-Yu Tsai 0 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-03-28 3:12 UTC (permalink / raw) To: Balsam CHIHI Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Mar 28, 2023 at 8:21 AM Balsam CHIHI <bchihi@baylibre.com> wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > Hi Chen-Yu, > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > Domain because you confirm that MCU Domain probe runs without issues. > > > Is it possible to test something for us to confirm this theory (i > > > don't have an mt8192 board on hand now), when you have the time of > > > course? > > > We would like to test AP Domain's calibration data offsets with a > > > working one, for example : > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > { > > > - .cal_offset = { 0x25, 0x28 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_VPU0 }, > > > { .dt_id = MT8192_AP_VPU1 } > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x2e, 0x31 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_GPU0 }, > > > { .dt_id = MT8192_AP_GPU1 } > > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x37, 0x3a }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_INFRA }, > > > { .dt_id = MT8192_AP_CAM }, > > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > > mt8192_lvts_ap_data_ctrl[] = { > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > }, > > > { > > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_MD0 }, > > > { .dt_id = MT8192_AP_MD1 }, > > > > > > This example is tested and works for mt8195, > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > Thank you in advance for your help. > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > then nothing trips. There's also a bug in the interrupt handling code > > that needs to be dealt with. > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > to pack data for the remaining sensors. > > > > Regards > > ChenYu > > Hi Chen-Yu Tsai, > > Thank you very much for helping me testing this suggestion. > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > So, the mt8192's support will be delayed for now, to allow further debugging. > > In the mean time, we will only continue to upstream the remaining > mt8195's source code, so it will get full LVTS support. > A new series will be submitted soon. > > Would you please point me out to the bug in interrupt handling code? I just sent out two patches and CC-ed you on them. They are here just in case: https://lore.kernel.org/linux-pm/20230328031037.1361048-1-wenst@chromium.org/ https://lore.kernel.org/linux-pm/20230328031017.1360976-1-wenst@chromium.org/ ChenYu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-28 3:12 ` Chen-Yu Tsai @ 2023-03-29 8:05 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-29 8:05 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, On Tue, Mar 28, 2023 at 5:12 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Tue, Mar 28, 2023 at 8:21 AM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x2e, 0x31 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_GPU0 }, > > > > { .dt_id = MT8192_AP_GPU1 } > > > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x37, 0x3a }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_INFRA }, > > > > { .dt_id = MT8192_AP_CAM }, > > > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_MD0 }, > > > > { .dt_id = MT8192_AP_MD1 }, > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > > > Would you please point me out to the bug in interrupt handling code? > > I just sent out two patches and CC-ed you on them. They are here just in case: > > https://lore.kernel.org/linux-pm/20230328031037.1361048-1-wenst@chromium.org/ > https://lore.kernel.org/linux-pm/20230328031017.1360976-1-wenst@chromium.org/ Well received. I'm testing it. Thanks! Best regards, Balsam > > ChenYu ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-03-29 8:05 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-03-29 8:05 UTC (permalink / raw) To: Chen-Yu Tsai Cc: daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen Hi Chen-Yu, On Tue, Mar 28, 2023 at 5:12 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Tue, Mar 28, 2023 at 8:21 AM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x2e, 0x31 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_GPU0 }, > > > > { .dt_id = MT8192_AP_GPU1 } > > > > @@ -1346,7 +1346,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x37, 0x3a }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_INFRA }, > > > > { .dt_id = MT8192_AP_CAM }, > > > > @@ -1356,7 +1356,7 @@ static const struct lvts_ctrl_data > > > > mt8192_lvts_ap_data_ctrl[] = { > > > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > > > }, > > > > { > > > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > > > + .cal_offset = { 0x04, 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_MD0 }, > > > > { .dt_id = MT8192_AP_MD1 }, > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > > > Would you please point me out to the bug in interrupt handling code? > > I just sent out two patches and CC-ed you on them. They are here just in case: > > https://lore.kernel.org/linux-pm/20230328031037.1361048-1-wenst@chromium.org/ > https://lore.kernel.org/linux-pm/20230328031017.1360976-1-wenst@chromium.org/ Well received. I'm testing it. Thanks! Best regards, Balsam > > ChenYu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-03-28 0:20 ` Balsam CHIHI @ 2023-04-24 22:21 ` Nícolas F. R. A. Prado -1 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-24 22:21 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > Hi Chen-Yu, > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > Domain because you confirm that MCU Domain probe runs without issues. > > > Is it possible to test something for us to confirm this theory (i > > > don't have an mt8192 board on hand now), when you have the time of > > > course? > > > We would like to test AP Domain's calibration data offsets with a > > > working one, for example : > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > { > > > - .cal_offset = { 0x25, 0x28 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_VPU0 }, > > > { .dt_id = MT8192_AP_VPU1 } > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data [..] > > > > > > This example is tested and works for mt8195, > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > Thank you in advance for your help. > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > then nothing trips. There's also a bug in the interrupt handling code > > that needs to be dealt with. > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > to pack data for the remaining sensors. > > > > Regards > > ChenYu > > Hi Chen-Yu Tsai, > > Thank you very much for helping me testing this suggestion. > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > So, the mt8192's support will be delayed for now, to allow further debugging. > > In the mean time, we will only continue to upstream the remaining > mt8195's source code, so it will get full LVTS support. > A new series will be submitted soon. Hi Balsam, like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for MT8192, but the data that is split between non-contiguous bytes is for the thermal controllers (called Resistor-Capacitor Calibration downstream) not the sensors. The controller calibration isn't currently handled in this driver (and downstream it also isn't used, since a current value is read from the controller instead), so we can just ignore those. The patch below adjusts the addresseses for the sensors and gives me reasonable reads, so the machine no longer reboots. Can you integrate it into your series? Thanks, Nícolas From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= <nfraprado@collabora.com> Date: Mon, 24 Apr 2023 17:42:42 -0400 Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration offsets for MT8192 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> --- drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c index b6956c89d557..f8afbc2ac190 100644 --- a/drivers/thermal/mediatek/lvts_thermal.c +++ b/drivers/thermal/mediatek/lvts_thermal.c @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { { - .cal_offset = { 0x04, 0x07 }, + .cal_offset = { 0x04, 0x08 }, .lvts_sensor = { { .dt_id = MT8192_MCU_BIG_CPU0 }, { .dt_id = MT8192_MCU_BIG_CPU1 } @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x0d, 0x10 }, + .cal_offset = { 0x0c, 0x10 }, .lvts_sensor = { { .dt_id = MT8192_MCU_BIG_CPU2 }, { .dt_id = MT8192_MCU_BIG_CPU3 } @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, .lvts_sensor = { { .dt_id = MT8192_MCU_LITTLE_CPU0 }, { .dt_id = MT8192_MCU_LITTLE_CPU1 }, @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { { - .cal_offset = { 0x25, 0x28 }, + .cal_offset = { 0x24, 0x28 }, .lvts_sensor = { { .dt_id = MT8192_AP_VPU0 }, { .dt_id = MT8192_AP_VPU1 } @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x2e, 0x31 }, + .cal_offset = { 0x2c, 0x30 }, .lvts_sensor = { { .dt_id = MT8192_AP_GPU0 }, { .dt_id = MT8192_AP_GPU1 } @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x37, 0x3a }, + .cal_offset = { 0x34, 0x38 }, .lvts_sensor = { { .dt_id = MT8192_AP_INFRA }, { .dt_id = MT8192_AP_CAM }, @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x40, 0x43, 0x46 }, + .cal_offset = { 0x3c, 0x40, 0x44 }, .lvts_sensor = { { .dt_id = MT8192_AP_MD0 }, { .dt_id = MT8192_AP_MD1 }, -- 2.40.0 ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-24 22:21 ` Nícolas F. R. A. Prado 0 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-24 22:21 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > Hi Chen-Yu, > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > Domain because you confirm that MCU Domain probe runs without issues. > > > Is it possible to test something for us to confirm this theory (i > > > don't have an mt8192 board on hand now), when you have the time of > > > course? > > > We would like to test AP Domain's calibration data offsets with a > > > working one, for example : > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > { > > > - .cal_offset = { 0x25, 0x28 }, > > > + .cal_offset = { 0x04, 0x04 }, > > > .lvts_sensor = { > > > { .dt_id = MT8192_AP_VPU0 }, > > > { .dt_id = MT8192_AP_VPU1 } > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data [..] > > > > > > This example is tested and works for mt8195, > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > Thank you in advance for your help. > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > then nothing trips. There's also a bug in the interrupt handling code > > that needs to be dealt with. > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > to pack data for the remaining sensors. > > > > Regards > > ChenYu > > Hi Chen-Yu Tsai, > > Thank you very much for helping me testing this suggestion. > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > So, the mt8192's support will be delayed for now, to allow further debugging. > > In the mean time, we will only continue to upstream the remaining > mt8195's source code, so it will get full LVTS support. > A new series will be submitted soon. Hi Balsam, like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for MT8192, but the data that is split between non-contiguous bytes is for the thermal controllers (called Resistor-Capacitor Calibration downstream) not the sensors. The controller calibration isn't currently handled in this driver (and downstream it also isn't used, since a current value is read from the controller instead), so we can just ignore those. The patch below adjusts the addresseses for the sensors and gives me reasonable reads, so the machine no longer reboots. Can you integrate it into your series? Thanks, Nícolas From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= <nfraprado@collabora.com> Date: Mon, 24 Apr 2023 17:42:42 -0400 Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration offsets for MT8192 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> --- drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c index b6956c89d557..f8afbc2ac190 100644 --- a/drivers/thermal/mediatek/lvts_thermal.c +++ b/drivers/thermal/mediatek/lvts_thermal.c @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { { - .cal_offset = { 0x04, 0x07 }, + .cal_offset = { 0x04, 0x08 }, .lvts_sensor = { { .dt_id = MT8192_MCU_BIG_CPU0 }, { .dt_id = MT8192_MCU_BIG_CPU1 } @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x0d, 0x10 }, + .cal_offset = { 0x0c, 0x10 }, .lvts_sensor = { { .dt_id = MT8192_MCU_BIG_CPU2 }, { .dt_id = MT8192_MCU_BIG_CPU3 } @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, .lvts_sensor = { { .dt_id = MT8192_MCU_LITTLE_CPU0 }, { .dt_id = MT8192_MCU_LITTLE_CPU1 }, @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { { - .cal_offset = { 0x25, 0x28 }, + .cal_offset = { 0x24, 0x28 }, .lvts_sensor = { { .dt_id = MT8192_AP_VPU0 }, { .dt_id = MT8192_AP_VPU1 } @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x2e, 0x31 }, + .cal_offset = { 0x2c, 0x30 }, .lvts_sensor = { { .dt_id = MT8192_AP_GPU0 }, { .dt_id = MT8192_AP_GPU1 } @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x37, 0x3a }, + .cal_offset = { 0x34, 0x38 }, .lvts_sensor = { { .dt_id = MT8192_AP_INFRA }, { .dt_id = MT8192_AP_CAM }, @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, }, { - .cal_offset = { 0x40, 0x43, 0x46 }, + .cal_offset = { 0x3c, 0x40, 0x44 }, .lvts_sensor = { { .dt_id = MT8192_AP_MD0 }, { .dt_id = MT8192_AP_MD1 }, -- 2.40.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-24 22:21 ` Nícolas F. R. A. Prado @ 2023-04-25 8:36 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-25 8:36 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 12:21 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > [..] > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > Hi Balsam, > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > MT8192, but the data that is split between non-contiguous bytes is for the > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > sensors. The controller calibration isn't currently handled in this driver (and > downstream it also isn't used, since a current value is read from the controller > instead), so we can just ignore those. > > The patch below adjusts the addresseses for the sensors and gives me reasonable > reads, so the machine no longer reboots. Can you integrate it into your series? > > Thanks, > Nícolas > Hello Nícolas, Thank you very much for your help! I really appreciate it. Yes, of course I will integrate your fix to the series immediately. Best regards, Balsam > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > <nfraprado@collabora.com> > Date: Mon, 24 Apr 2023 17:42:42 -0400 > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > offsets for MT8192 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > --- > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > index b6956c89d557..f8afbc2ac190 100644 > --- a/drivers/thermal/mediatek/lvts_thermal.c > +++ b/drivers/thermal/mediatek/lvts_thermal.c > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > { > - .cal_offset = { 0x04, 0x07 }, > + .cal_offset = { 0x04, 0x08 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU0 }, > { .dt_id = MT8192_MCU_BIG_CPU1 } > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x0d, 0x10 }, > + .cal_offset = { 0x0c, 0x10 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU2 }, > { .dt_id = MT8192_MCU_BIG_CPU3 } > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x24, 0x28 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x2c, 0x30 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x34, 0x38 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x3c, 0x40, 0x44 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > -- > 2.40.0 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-25 8:36 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-25 8:36 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 12:21 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > [..] > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > Hi Balsam, > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > MT8192, but the data that is split between non-contiguous bytes is for the > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > sensors. The controller calibration isn't currently handled in this driver (and > downstream it also isn't used, since a current value is read from the controller > instead), so we can just ignore those. > > The patch below adjusts the addresseses for the sensors and gives me reasonable > reads, so the machine no longer reboots. Can you integrate it into your series? > > Thanks, > Nícolas > Hello Nícolas, Thank you very much for your help! I really appreciate it. Yes, of course I will integrate your fix to the series immediately. Best regards, Balsam > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > <nfraprado@collabora.com> > Date: Mon, 24 Apr 2023 17:42:42 -0400 > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > offsets for MT8192 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > --- > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > index b6956c89d557..f8afbc2ac190 100644 > --- a/drivers/thermal/mediatek/lvts_thermal.c > +++ b/drivers/thermal/mediatek/lvts_thermal.c > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > { > - .cal_offset = { 0x04, 0x07 }, > + .cal_offset = { 0x04, 0x08 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU0 }, > { .dt_id = MT8192_MCU_BIG_CPU1 } > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x0d, 0x10 }, > + .cal_offset = { 0x0c, 0x10 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU2 }, > { .dt_id = MT8192_MCU_BIG_CPU3 } > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x24, 0x28 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x2c, 0x30 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x34, 0x38 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x3c, 0x40, 0x44 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > -- > 2.40.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-24 22:21 ` Nícolas F. R. A. Prado @ 2023-04-25 9:59 ` Chen-Yu Tsai -1 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-04-25 9:59 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Balsam CHIHI, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > [..] > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > Hi Balsam, > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > MT8192, but the data that is split between non-contiguous bytes is for the > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > sensors. The controller calibration isn't currently handled in this driver (and > downstream it also isn't used, since a current value is read from the controller > instead), so we can just ignore those. > > The patch below adjusts the addresseses for the sensors and gives me reasonable > reads, so the machine no longer reboots. Can you integrate it into your series? Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts are still tripping excessively. The readings seem normal though. Specifically, it's bits 16 and 17 that are tripping. > Thanks, > Nícolas > > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > <nfraprado@collabora.com> > Date: Mon, 24 Apr 2023 17:42:42 -0400 > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > offsets for MT8192 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > --- > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > index b6956c89d557..f8afbc2ac190 100644 > --- a/drivers/thermal/mediatek/lvts_thermal.c > +++ b/drivers/thermal/mediatek/lvts_thermal.c > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > { > - .cal_offset = { 0x04, 0x07 }, > + .cal_offset = { 0x04, 0x08 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU0 }, > { .dt_id = MT8192_MCU_BIG_CPU1 } > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x0d, 0x10 }, > + .cal_offset = { 0x0c, 0x10 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU2 }, > { .dt_id = MT8192_MCU_BIG_CPU3 } > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x24, 0x28 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x2c, 0x30 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x34, 0x38 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x3c, 0x40, 0x44 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > -- > 2.40.0 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-25 9:59 ` Chen-Yu Tsai 0 siblings, 0 replies; 46+ messages in thread From: Chen-Yu Tsai @ 2023-04-25 9:59 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Balsam CHIHI, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > Hi Chen-Yu, > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > Is it possible to test something for us to confirm this theory (i > > > > don't have an mt8192 board on hand now), when you have the time of > > > > course? > > > > We would like to test AP Domain's calibration data offsets with a > > > > working one, for example : > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > { > > > > - .cal_offset = { 0x25, 0x28 }, > > > > + .cal_offset = { 0x04, 0x04 }, > > > > .lvts_sensor = { > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > { .dt_id = MT8192_AP_VPU1 } > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > [..] > > > > > > > > This example is tested and works for mt8195, > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > Thank you in advance for your help. > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > then nothing trips. There's also a bug in the interrupt handling code > > > that needs to be dealt with. > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > to pack data for the remaining sensors. > > > > > > Regards > > > ChenYu > > > > Hi Chen-Yu Tsai, > > > > Thank you very much for helping me testing this suggestion. > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > In the mean time, we will only continue to upstream the remaining > > mt8195's source code, so it will get full LVTS support. > > A new series will be submitted soon. > > Hi Balsam, > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > MT8192, but the data that is split between non-contiguous bytes is for the > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > sensors. The controller calibration isn't currently handled in this driver (and > downstream it also isn't used, since a current value is read from the controller > instead), so we can just ignore those. > > The patch below adjusts the addresseses for the sensors and gives me reasonable > reads, so the machine no longer reboots. Can you integrate it into your series? Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts are still tripping excessively. The readings seem normal though. Specifically, it's bits 16 and 17 that are tripping. > Thanks, > Nícolas > > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > <nfraprado@collabora.com> > Date: Mon, 24 Apr 2023 17:42:42 -0400 > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > offsets for MT8192 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > --- > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > index b6956c89d557..f8afbc2ac190 100644 > --- a/drivers/thermal/mediatek/lvts_thermal.c > +++ b/drivers/thermal/mediatek/lvts_thermal.c > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > { > - .cal_offset = { 0x04, 0x07 }, > + .cal_offset = { 0x04, 0x08 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU0 }, > { .dt_id = MT8192_MCU_BIG_CPU1 } > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x0d, 0x10 }, > + .cal_offset = { 0x0c, 0x10 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_BIG_CPU2 }, > { .dt_id = MT8192_MCU_BIG_CPU3 } > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > .lvts_sensor = { > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > { > - .cal_offset = { 0x25, 0x28 }, > + .cal_offset = { 0x24, 0x28 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_VPU0 }, > { .dt_id = MT8192_AP_VPU1 } > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x2e, 0x31 }, > + .cal_offset = { 0x2c, 0x30 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_GPU0 }, > { .dt_id = MT8192_AP_GPU1 } > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x37, 0x3a }, > + .cal_offset = { 0x34, 0x38 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_INFRA }, > { .dt_id = MT8192_AP_CAM }, > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > }, > { > - .cal_offset = { 0x40, 0x43, 0x46 }, > + .cal_offset = { 0x3c, 0x40, 0x44 }, > .lvts_sensor = { > { .dt_id = MT8192_AP_MD0 }, > { .dt_id = MT8192_AP_MD1 }, > -- > 2.40.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-25 9:59 ` Chen-Yu Tsai @ 2023-04-25 11:28 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-25 11:28 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Nícolas F. R. A. Prado, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > <nfraprado@collabora.com> wrote: > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > > > Hi Chen-Yu, > > > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > > Is it possible to test something for us to confirm this theory (i > > > > > don't have an mt8192 board on hand now), when you have the time of > > > > > course? > > > > > We would like to test AP Domain's calibration data offsets with a > > > > > working one, for example : > > > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > > { > > > > > - .cal_offset = { 0x25, 0x28 }, > > > > > + .cal_offset = { 0x04, 0x04 }, > > > > > .lvts_sensor = { > > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > > { .dt_id = MT8192_AP_VPU1 } > > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > [..] > > > > > > > > > > This example is tested and works for mt8195, > > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > > > Thank you in advance for your help. > > > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > > then nothing trips. There's also a bug in the interrupt handling code > > > > that needs to be dealt with. > > > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > > to pack data for the remaining sensors. > > > > > > > > Regards > > > > ChenYu > > > > > > Hi Chen-Yu Tsai, > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > In the mean time, we will only continue to upstream the remaining > > > mt8195's source code, so it will get full LVTS support. > > > A new series will be submitted soon. > > > > Hi Balsam, > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > MT8192, but the data that is split between non-contiguous bytes is for the > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > sensors. The controller calibration isn't currently handled in this driver (and > > downstream it also isn't used, since a current value is read from the controller > > instead), so we can just ignore those. > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > reads, so the machine no longer reboots. Can you integrate it into your series? > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > are still tripping excessively. The readings seem normal though. Specifically, > it's bits 16 and 17 that are tripping. > Hi Chen-Yu, Thank you for testing! As the readings are normal that proves that calibration data offsets are correct. would you like that I send the v2 of series to add mt8192 support? Then we could deal with the interrupts later in a separate fix, because the interrupt code in common for both SoC (mt8192 and mt8195)? Does Nícolas also have tripping interrupts? On my side, I've got no interrupts tripping on mt8195. Any other suggestions (a question for everyone)? Best regards, Balsam > > Thanks, > > Nícolas > > > > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > > <nfraprado@collabora.com> > > Date: Mon, 24 Apr 2023 17:42:42 -0400 > > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > > offsets for MT8192 > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > --- > > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > > index b6956c89d557..f8afbc2ac190 100644 > > --- a/drivers/thermal/mediatek/lvts_thermal.c > > +++ b/drivers/thermal/mediatek/lvts_thermal.c > > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > { > > - .cal_offset = { 0x04, 0x07 }, > > + .cal_offset = { 0x04, 0x08 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_BIG_CPU0 }, > > { .dt_id = MT8192_MCU_BIG_CPU1 } > > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x0d, 0x10 }, > > + .cal_offset = { 0x0c, 0x10 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_BIG_CPU2 }, > > { .dt_id = MT8192_MCU_BIG_CPU3 } > > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > { > > - .cal_offset = { 0x25, 0x28 }, > > + .cal_offset = { 0x24, 0x28 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_VPU0 }, > > { .dt_id = MT8192_AP_VPU1 } > > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x2e, 0x31 }, > > + .cal_offset = { 0x2c, 0x30 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_GPU0 }, > > { .dt_id = MT8192_AP_GPU1 } > > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x37, 0x3a }, > > + .cal_offset = { 0x34, 0x38 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_INFRA }, > > { .dt_id = MT8192_AP_CAM }, > > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > + .cal_offset = { 0x3c, 0x40, 0x44 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_MD0 }, > > { .dt_id = MT8192_AP_MD1 }, > > -- > > 2.40.0 ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-25 11:28 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-25 11:28 UTC (permalink / raw) To: Chen-Yu Tsai Cc: Nícolas F. R. A. Prado, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > <nfraprado@collabora.com> wrote: > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > > > > > > > > > Hi Chen-Yu, > > > > > > > > > > I suspect the bug comes from incorrect calibration data offsets for AP > > > > > Domain because you confirm that MCU Domain probe runs without issues. > > > > > Is it possible to test something for us to confirm this theory (i > > > > > don't have an mt8192 board on hand now), when you have the time of > > > > > course? > > > > > We would like to test AP Domain's calibration data offsets with a > > > > > working one, for example : > > > > > > > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > > > > { > > > > > - .cal_offset = { 0x25, 0x28 }, > > > > > + .cal_offset = { 0x04, 0x04 }, > > > > > .lvts_sensor = { > > > > > { .dt_id = MT8192_AP_VPU0 }, > > > > > { .dt_id = MT8192_AP_VPU1 } > > > > > @@ -1336,7 +1336,7 @@ static const struct lvts_ctrl_data > > [..] > > > > > > > > > > This example is tested and works for mt8195, > > > > > (all sensors use the same calibration data offset for testing purposes). > > > > > > > > > > Thank you in advance for your help. > > > > > > > > The MCU ones are still tripping though. If I change all of them to 0x04, > > > > then nothing trips. There's also a bug in the interrupt handling code > > > > that needs to be dealt with. > > > > > > > > AFAICT the calibration data is stored differently. If you look at ChromeOS's > > > > downstream v5.10 driver, you'll see mt6873_efuse_to_cal_data() for MT8192, > > > > and mt8195_efuse_to_cal_data() for MT8195. The difference sums up to: > > > > MT8195 has all data sequentially stored, while MT8192 has most data stored > > > > in lower 24 bits of each 32-bit word, and the highest 8 bits are then used > > > > to pack data for the remaining sensors. > > > > > > > > Regards > > > > ChenYu > > > > > > Hi Chen-Yu Tsai, > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > In the mean time, we will only continue to upstream the remaining > > > mt8195's source code, so it will get full LVTS support. > > > A new series will be submitted soon. > > > > Hi Balsam, > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > MT8192, but the data that is split between non-contiguous bytes is for the > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > sensors. The controller calibration isn't currently handled in this driver (and > > downstream it also isn't used, since a current value is read from the controller > > instead), so we can just ignore those. > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > reads, so the machine no longer reboots. Can you integrate it into your series? > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > are still tripping excessively. The readings seem normal though. Specifically, > it's bits 16 and 17 that are tripping. > Hi Chen-Yu, Thank you for testing! As the readings are normal that proves that calibration data offsets are correct. would you like that I send the v2 of series to add mt8192 support? Then we could deal with the interrupts later in a separate fix, because the interrupt code in common for both SoC (mt8192 and mt8195)? Does Nícolas also have tripping interrupts? On my side, I've got no interrupts tripping on mt8195. Any other suggestions (a question for everyone)? Best regards, Balsam > > Thanks, > > Nícolas > > > > From 4506f03b806f3eeb89887bac2c1c86d61da97281 Mon Sep 17 00:00:00 2001 > > From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= > > <nfraprado@collabora.com> > > Date: Mon, 24 Apr 2023 17:42:42 -0400 > > Subject: [PATCH] thermal/drivers/mediatek/lvts_thermal: Fix calibration > > offsets for MT8192 > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> > > --- > > drivers/thermal/mediatek/lvts_thermal.c | 14 +++++++------- > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c > > index b6956c89d557..f8afbc2ac190 100644 > > --- a/drivers/thermal/mediatek/lvts_thermal.c > > +++ b/drivers/thermal/mediatek/lvts_thermal.c > > @@ -1261,7 +1261,7 @@ static const struct lvts_ctrl_data mt8195_lvts_ap_data_ctrl[] = { > > > > static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > { > > - .cal_offset = { 0x04, 0x07 }, > > + .cal_offset = { 0x04, 0x08 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_BIG_CPU0 }, > > { .dt_id = MT8192_MCU_BIG_CPU1 } > > @@ -1271,7 +1271,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x0d, 0x10 }, > > + .cal_offset = { 0x0c, 0x10 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_BIG_CPU2 }, > > { .dt_id = MT8192_MCU_BIG_CPU3 } > > @@ -1281,7 +1281,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x16, 0x19, 0x1c, 0x1f }, > > + .cal_offset = { 0x14, 0x18, 0x1c, 0x20 }, > > .lvts_sensor = { > > { .dt_id = MT8192_MCU_LITTLE_CPU0 }, > > { .dt_id = MT8192_MCU_LITTLE_CPU1 }, > > @@ -1296,7 +1296,7 @@ static const struct lvts_ctrl_data mt8192_lvts_mcu_data_ctrl[] = { > > > > static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > { > > - .cal_offset = { 0x25, 0x28 }, > > + .cal_offset = { 0x24, 0x28 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_VPU0 }, > > { .dt_id = MT8192_AP_VPU1 } > > @@ -1306,7 +1306,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x2e, 0x31 }, > > + .cal_offset = { 0x2c, 0x30 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_GPU0 }, > > { .dt_id = MT8192_AP_GPU1 } > > @@ -1316,7 +1316,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x37, 0x3a }, > > + .cal_offset = { 0x34, 0x38 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_INFRA }, > > { .dt_id = MT8192_AP_CAM }, > > @@ -1326,7 +1326,7 @@ static const struct lvts_ctrl_data mt8192_lvts_ap_data_ctrl[] = { > > .hw_tshut_temp = LVTS_HW_SHUTDOWN_MT8192, > > }, > > { > > - .cal_offset = { 0x40, 0x43, 0x46 }, > > + .cal_offset = { 0x3c, 0x40, 0x44 }, > > .lvts_sensor = { > > { .dt_id = MT8192_AP_MD0 }, > > { .dt_id = MT8192_AP_MD1 }, > > -- > > 2.40.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-25 11:28 ` Balsam CHIHI @ 2023-04-26 23:20 ` Nícolas F. R. A. Prado -1 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-26 23:20 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > <nfraprado@collabora.com> wrote: > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: [..] > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > mt8195's source code, so it will get full LVTS support. > > > > A new series will be submitted soon. > > > > > > Hi Balsam, > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > sensors. The controller calibration isn't currently handled in this driver (and > > > downstream it also isn't used, since a current value is read from the controller > > > instead), so we can just ignore those. > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > are still tripping excessively. The readings seem normal though. Specifically, > > it's bits 16 and 17 that are tripping. > > > > Hi Chen-Yu, > > Thank you for testing! > > As the readings are normal that proves that calibration data offsets > are correct. > would you like that I send the v2 of series to add mt8192 support? > Then we could deal with the interrupts later in a separate fix, > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > Does Nícolas also have tripping interrupts? > On my side, I've got no interrupts tripping on mt8195. > > Any other suggestions (a question for everyone)? Hi, sorry for the delay. Indeed the interrupts are constantly tripping on mt8192 here as well. I do not see the same bits as Chen-Yu mentioned however, I see LVTS_MONINTSTS = 0x08070000 which corresponds to Hot threshold on sense point 3 high to normal offset on sense point 2 high offset on sense point 2 low offset on sense point 2 and it's the same on all controllers and domains here, which is weird. I noticed we have offset interrupts enabled even though we don't configure the values for those, but even after disabling them and clearing the status register, the interrupts keep triggering and the status is the same, so for some reason LVTS_MONINT doesn't seem to be honored. I also tried using the filtered mode instead of immediate for the sensors, and that together with disabling the extra interrupts, got me a zeroed LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor LVTS_MONINTSTS updated) when the temperature goes over the configured one in LVTS_HTHRE. I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same LVTS_MONINTSTS = 0x08070000 even though the interrupts aren't being triggered, but in fact I don't see them triggering over the threshold either, so I suspect the irq number might be incorrectly described in the DT there. Do either of you have it working correctly on mt8195? Anyway, I'll keep digging and reply here when I find a solution. Thanks, Nícolas ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-26 23:20 ` Nícolas F. R. A. Prado 0 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-26 23:20 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > <nfraprado@collabora.com> wrote: > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: [..] > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > mt8195's source code, so it will get full LVTS support. > > > > A new series will be submitted soon. > > > > > > Hi Balsam, > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > sensors. The controller calibration isn't currently handled in this driver (and > > > downstream it also isn't used, since a current value is read from the controller > > > instead), so we can just ignore those. > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > are still tripping excessively. The readings seem normal though. Specifically, > > it's bits 16 and 17 that are tripping. > > > > Hi Chen-Yu, > > Thank you for testing! > > As the readings are normal that proves that calibration data offsets > are correct. > would you like that I send the v2 of series to add mt8192 support? > Then we could deal with the interrupts later in a separate fix, > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > Does Nícolas also have tripping interrupts? > On my side, I've got no interrupts tripping on mt8195. > > Any other suggestions (a question for everyone)? Hi, sorry for the delay. Indeed the interrupts are constantly tripping on mt8192 here as well. I do not see the same bits as Chen-Yu mentioned however, I see LVTS_MONINTSTS = 0x08070000 which corresponds to Hot threshold on sense point 3 high to normal offset on sense point 2 high offset on sense point 2 low offset on sense point 2 and it's the same on all controllers and domains here, which is weird. I noticed we have offset interrupts enabled even though we don't configure the values for those, but even after disabling them and clearing the status register, the interrupts keep triggering and the status is the same, so for some reason LVTS_MONINT doesn't seem to be honored. I also tried using the filtered mode instead of immediate for the sensors, and that together with disabling the extra interrupts, got me a zeroed LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor LVTS_MONINTSTS updated) when the temperature goes over the configured one in LVTS_HTHRE. I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same LVTS_MONINTSTS = 0x08070000 even though the interrupts aren't being triggered, but in fact I don't see them triggering over the threshold either, so I suspect the irq number might be incorrectly described in the DT there. Do either of you have it working correctly on mt8195? Anyway, I'll keep digging and reply here when I find a solution. Thanks, Nícolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-26 23:20 ` Nícolas F. R. A. Prado @ 2023-04-27 14:08 ` Balsam CHIHI -1 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-27 14:08 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen, Alexandre Bailon, Alexandre Mergnat On Thu, Apr 27, 2023 at 1:20 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > > <nfraprado@collabora.com> wrote: > > > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > [..] > > > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > > mt8195's source code, so it will get full LVTS support. > > > > > A new series will be submitted soon. > > > > > > > > Hi Balsam, > > > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > > sensors. The controller calibration isn't currently handled in this driver (and > > > > downstream it also isn't used, since a current value is read from the controller > > > > instead), so we can just ignore those. > > > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > > are still tripping excessively. The readings seem normal though. Specifically, > > > it's bits 16 and 17 that are tripping. > > > > > > > Hi Chen-Yu, > > > > Thank you for testing! > > > > As the readings are normal that proves that calibration data offsets > > are correct. > > would you like that I send the v2 of series to add mt8192 support? > > Then we could deal with the interrupts later in a separate fix, > > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > > > Does Nícolas also have tripping interrupts? > > On my side, I've got no interrupts tripping on mt8195. > > > > Any other suggestions (a question for everyone)? > > Hi, > > sorry for the delay. > > Indeed the interrupts are constantly tripping on mt8192 here as well. > > I do not see the same bits as Chen-Yu mentioned however, I see > > LVTS_MONINTSTS = 0x08070000 > > which corresponds to > > Hot threshold on sense point 3 > high to normal offset on sense point 2 > high offset on sense point 2 > low offset on sense point 2 > > and it's the same on all controllers and domains here, which is weird. I noticed > we have offset interrupts enabled even though we don't configure the values for > those, but even after disabling them and clearing the status register, the > interrupts keep triggering and the status is the same, so for some reason > LVTS_MONINT doesn't seem to be honored. > > I also tried using the filtered mode instead of immediate for the sensors, and > that together with disabling the extra interrupts, got me a zeroed > LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor > LVTS_MONINTSTS updated) when the temperature goes over the configured one in > LVTS_HTHRE. > > I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same > LVTS_MONINTSTS = 0x08070000 > even though the interrupts aren't being triggered, but in fact I don't see them > triggering over the threshold either, so I suspect the irq number might be > incorrectly described in the DT there. > > Do either of you have it working correctly on mt8195? > > Anyway, I'll keep digging and reply here when I find a solution. Hi Nícolas, Thank your for your time testing and investigating the interrupt issues! I only have an mt8195 based board (i1200-demo), and I could not trigger any interrupt on it. I whish that MediaTek could reply to this thread to give us more information (I avoid disclosing MediaTek's internal information). And now, it's clear that mt8192 interrupts does work at least (but not properly, may be we could fix it at driver level). It's been a couple of days since I sent a v2 of the series that adds LVTS support for mt8192 SoC (+ Suspend and Resume, + Doc update): "https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/". I wish that it will be applied very soon, then we could patch the core driver. My colleagues "Alexandre Mergnat (amergnat@baylibre.com)" and "Alexandre Bailon (abailon@baylibre.com)" are now part of this project. Please let them know of future information. Thanks again for suggesting solutions! Best regards, Balsam > > Thanks, > Nícolas ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-27 14:08 ` Balsam CHIHI 0 siblings, 0 replies; 46+ messages in thread From: Balsam CHIHI @ 2023-04-27 14:08 UTC (permalink / raw) To: Nícolas F. R. A. Prado Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen, Alexandre Bailon, Alexandre Mergnat On Thu, Apr 27, 2023 at 1:20 AM Nícolas F. R. A. Prado <nfraprado@collabora.com> wrote: > > On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > > <nfraprado@collabora.com> wrote: > > > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > [..] > > > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > > mt8195's source code, so it will get full LVTS support. > > > > > A new series will be submitted soon. > > > > > > > > Hi Balsam, > > > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > > sensors. The controller calibration isn't currently handled in this driver (and > > > > downstream it also isn't used, since a current value is read from the controller > > > > instead), so we can just ignore those. > > > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > > are still tripping excessively. The readings seem normal though. Specifically, > > > it's bits 16 and 17 that are tripping. > > > > > > > Hi Chen-Yu, > > > > Thank you for testing! > > > > As the readings are normal that proves that calibration data offsets > > are correct. > > would you like that I send the v2 of series to add mt8192 support? > > Then we could deal with the interrupts later in a separate fix, > > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > > > Does Nícolas also have tripping interrupts? > > On my side, I've got no interrupts tripping on mt8195. > > > > Any other suggestions (a question for everyone)? > > Hi, > > sorry for the delay. > > Indeed the interrupts are constantly tripping on mt8192 here as well. > > I do not see the same bits as Chen-Yu mentioned however, I see > > LVTS_MONINTSTS = 0x08070000 > > which corresponds to > > Hot threshold on sense point 3 > high to normal offset on sense point 2 > high offset on sense point 2 > low offset on sense point 2 > > and it's the same on all controllers and domains here, which is weird. I noticed > we have offset interrupts enabled even though we don't configure the values for > those, but even after disabling them and clearing the status register, the > interrupts keep triggering and the status is the same, so for some reason > LVTS_MONINT doesn't seem to be honored. > > I also tried using the filtered mode instead of immediate for the sensors, and > that together with disabling the extra interrupts, got me a zeroed > LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor > LVTS_MONINTSTS updated) when the temperature goes over the configured one in > LVTS_HTHRE. > > I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same > LVTS_MONINTSTS = 0x08070000 > even though the interrupts aren't being triggered, but in fact I don't see them > triggering over the threshold either, so I suspect the irq number might be > incorrectly described in the DT there. > > Do either of you have it working correctly on mt8195? > > Anyway, I'll keep digging and reply here when I find a solution. Hi Nícolas, Thank your for your time testing and investigating the interrupt issues! I only have an mt8195 based board (i1200-demo), and I could not trigger any interrupt on it. I whish that MediaTek could reply to this thread to give us more information (I avoid disclosing MediaTek's internal information). And now, it's clear that mt8192 interrupts does work at least (but not properly, may be we could fix it at driver level). It's been a couple of days since I sent a v2 of the series that adds LVTS support for mt8192 SoC (+ Suspend and Resume, + Doc update): "https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/". I wish that it will be applied very soon, then we could patch the core driver. My colleagues "Alexandre Mergnat (amergnat@baylibre.com)" and "Alexandre Bailon (abailon@baylibre.com)" are now part of this project. Please let them know of future information. Thanks again for suggesting solutions! Best regards, Balsam > > Thanks, > Nícolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 2023-04-27 14:08 ` Balsam CHIHI @ 2023-04-28 20:00 ` Nícolas F. R. A. Prado -1 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-28 20:00 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen, Alexandre Bailon, Alexandre Mergnat On Thu, Apr 27, 2023 at 04:08:13PM +0200, Balsam CHIHI wrote: > On Thu, Apr 27, 2023 at 1:20 AM Nícolas F. R. A. Prado > <nfraprado@collabora.com> wrote: > > > > On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > > > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > > > <nfraprado@collabora.com> wrote: > > > > > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > [..] > > > > > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > > > mt8195's source code, so it will get full LVTS support. > > > > > > A new series will be submitted soon. > > > > > > > > > > Hi Balsam, > > > > > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > > > sensors. The controller calibration isn't currently handled in this driver (and > > > > > downstream it also isn't used, since a current value is read from the controller > > > > > instead), so we can just ignore those. > > > > > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > > > are still tripping excessively. The readings seem normal though. Specifically, > > > > it's bits 16 and 17 that are tripping. > > > > > > > > > > Hi Chen-Yu, > > > > > > Thank you for testing! > > > > > > As the readings are normal that proves that calibration data offsets > > > are correct. > > > would you like that I send the v2 of series to add mt8192 support? > > > Then we could deal with the interrupts later in a separate fix, > > > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > > > > > Does Nícolas also have tripping interrupts? > > > On my side, I've got no interrupts tripping on mt8195. > > > > > > Any other suggestions (a question for everyone)? > > > > Hi, > > > > sorry for the delay. > > > > Indeed the interrupts are constantly tripping on mt8192 here as well. > > > > I do not see the same bits as Chen-Yu mentioned however, I see > > > > LVTS_MONINTSTS = 0x08070000 > > > > which corresponds to > > > > Hot threshold on sense point 3 > > high to normal offset on sense point 2 > > high offset on sense point 2 > > low offset on sense point 2 > > > > and it's the same on all controllers and domains here, which is weird. I noticed > > we have offset interrupts enabled even though we don't configure the values for > > those, but even after disabling them and clearing the status register, the > > interrupts keep triggering and the status is the same, so for some reason > > LVTS_MONINT doesn't seem to be honored. > > > > I also tried using the filtered mode instead of immediate for the sensors, and > > that together with disabling the extra interrupts, got me a zeroed > > LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor > > LVTS_MONINTSTS updated) when the temperature goes over the configured one in > > LVTS_HTHRE. > > > > I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same > > LVTS_MONINTSTS = 0x08070000 > > even though the interrupts aren't being triggered, but in fact I don't see them > > triggering over the threshold either, so I suspect the irq number might be > > incorrectly described in the DT there. > > > > Do either of you have it working correctly on mt8195? > > > > Anyway, I'll keep digging and reply here when I find a solution. > > Hi Nícolas, > > Thank your for your time testing and investigating the interrupt issues! > > I only have an mt8195 based board (i1200-demo), and I could not > trigger any interrupt on it. > I whish that MediaTek could reply to this thread to give us more > information (I avoid disclosing MediaTek's internal information). > And now, it's clear that mt8192 interrupts does work at least (but not > properly, may be we could fix it at driver level). > > It's been a couple of days since I sent a v2 of the series that adds > LVTS support for mt8192 SoC (+ Suspend and Resume, + Doc update): > "https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/". > I wish that it will be applied very soon, then we could patch the core driver. > > My colleagues "Alexandre Mergnat (amergnat@baylibre.com)" and > "Alexandre Bailon (abailon@baylibre.com)" are now part of this > project. > Please let them know of future information. > > Thanks again for suggesting solutions! Hi, finally managed to fix the issues. I had mis-read the interrupt status bits, which made things a whole lot more confusing... I CC'ed you on the series, but for the archive this is it: https://lore.kernel.org/all/20230428195347.3832687-1-nfraprado@collabora.com/ Please review/test it if you have the time. I have one extra comment regarding the mt8192 support, but I'll write it on the v2 of this series. Thanks, Nícolas ^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 0/4] Add LVTS support for mt8192 @ 2023-04-28 20:00 ` Nícolas F. R. A. Prado 0 siblings, 0 replies; 46+ messages in thread From: Nícolas F. R. A. Prado @ 2023-04-28 20:00 UTC (permalink / raw) To: Balsam CHIHI Cc: Chen-Yu Tsai, daniel.lezcano, angelogioacchino.delregno, rafael, amitk, rui.zhang, matthias.bgg, robh+dt, krzysztof.kozlowski+dt, rdunlap, ye.xingchen, p.zabel, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek, devicetree, khilman, james.lo, rex-bc.chen, Alexandre Bailon, Alexandre Mergnat On Thu, Apr 27, 2023 at 04:08:13PM +0200, Balsam CHIHI wrote: > On Thu, Apr 27, 2023 at 1:20 AM Nícolas F. R. A. Prado > <nfraprado@collabora.com> wrote: > > > > On Tue, Apr 25, 2023 at 01:28:39PM +0200, Balsam CHIHI wrote: > > > On Tue, Apr 25, 2023 at 12:00 PM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > On Tue, Apr 25, 2023 at 6:21 AM Nícolas F. R. A. Prado > > > > <nfraprado@collabora.com> wrote: > > > > > > > > > > On Tue, Mar 28, 2023 at 02:20:24AM +0200, Balsam CHIHI wrote: > > > > > > On Sat, Mar 25, 2023 at 5:33 AM Chen-Yu Tsai <wenst@chromium.org> wrote: > > > > > > > > > > > > > > On Wed, Mar 22, 2023 at 8:48 PM Balsam CHIHI <bchihi@baylibre.com> wrote: > > [..] > > > > > > > > > > > > Hi Chen-Yu Tsai, > > > > > > > > > > > > Thank you very much for helping me testing this suggestion. > > > > > > > > > > > > Indeed, calibration data is stored differently in the mt8192 compared to mt8195. > > > > > > So, the mt8192's support will be delayed for now, to allow further debugging. > > > > > > > > > > > > In the mean time, we will only continue to upstream the remaining > > > > > > mt8195's source code, so it will get full LVTS support. > > > > > > A new series will be submitted soon. > > > > > > > > > > Hi Balsam, > > > > > > > > > > like Chen-Yu mentioned, the calibration data is stored with 4 byte alignment for > > > > > MT8192, but the data that is split between non-contiguous bytes is for the > > > > > thermal controllers (called Resistor-Capacitor Calibration downstream) not the > > > > > sensors. The controller calibration isn't currently handled in this driver (and > > > > > downstream it also isn't used, since a current value is read from the controller > > > > > instead), so we can just ignore those. > > > > > > > > > > The patch below adjusts the addresseses for the sensors and gives me reasonable > > > > > reads, so the machine no longer reboots. Can you integrate it into your series? > > > > > > > > Not sure what I got wrong, but on my machine the VPU0 and VPU1 zone interrupts > > > > are still tripping excessively. The readings seem normal though. Specifically, > > > > it's bits 16 and 17 that are tripping. > > > > > > > > > > Hi Chen-Yu, > > > > > > Thank you for testing! > > > > > > As the readings are normal that proves that calibration data offsets > > > are correct. > > > would you like that I send the v2 of series to add mt8192 support? > > > Then we could deal with the interrupts later in a separate fix, > > > because the interrupt code in common for both SoC (mt8192 and mt8195)? > > > > > > Does Nícolas also have tripping interrupts? > > > On my side, I've got no interrupts tripping on mt8195. > > > > > > Any other suggestions (a question for everyone)? > > > > Hi, > > > > sorry for the delay. > > > > Indeed the interrupts are constantly tripping on mt8192 here as well. > > > > I do not see the same bits as Chen-Yu mentioned however, I see > > > > LVTS_MONINTSTS = 0x08070000 > > > > which corresponds to > > > > Hot threshold on sense point 3 > > high to normal offset on sense point 2 > > high offset on sense point 2 > > low offset on sense point 2 > > > > and it's the same on all controllers and domains here, which is weird. I noticed > > we have offset interrupts enabled even though we don't configure the values for > > those, but even after disabling them and clearing the status register, the > > interrupts keep triggering and the status is the same, so for some reason > > LVTS_MONINT doesn't seem to be honored. > > > > I also tried using the filtered mode instead of immediate for the sensors, and > > that together with disabling the extra interrupts, got me a zeroed > > LVTS_MONINTSTS. However no interrupts seem to be triggered at all (nor > > LVTS_MONINTSTS updated) when the temperature goes over the configured one in > > LVTS_HTHRE. > > > > I tried the driver on mt8195 (Tomato chromebook) as well, and it has the same > > LVTS_MONINTSTS = 0x08070000 > > even though the interrupts aren't being triggered, but in fact I don't see them > > triggering over the threshold either, so I suspect the irq number might be > > incorrectly described in the DT there. > > > > Do either of you have it working correctly on mt8195? > > > > Anyway, I'll keep digging and reply here when I find a solution. > > Hi Nícolas, > > Thank your for your time testing and investigating the interrupt issues! > > I only have an mt8195 based board (i1200-demo), and I could not > trigger any interrupt on it. > I whish that MediaTek could reply to this thread to give us more > information (I avoid disclosing MediaTek's internal information). > And now, it's clear that mt8192 interrupts does work at least (but not > properly, may be we could fix it at driver level). > > It's been a couple of days since I sent a v2 of the series that adds > LVTS support for mt8192 SoC (+ Suspend and Resume, + Doc update): > "https://lore.kernel.org/all/20230425133052.199767-1-bchihi@baylibre.com/". > I wish that it will be applied very soon, then we could patch the core driver. > > My colleagues "Alexandre Mergnat (amergnat@baylibre.com)" and > "Alexandre Bailon (abailon@baylibre.com)" are now part of this > project. > Please let them know of future information. > > Thanks again for suggesting solutions! Hi, finally managed to fix the issues. I had mis-read the interrupt status bits, which made things a whole lot more confusing... I CC'ed you on the series, but for the archive this is it: https://lore.kernel.org/all/20230428195347.3832687-1-nfraprado@collabora.com/ Please review/test it if you have the time. I have one extra comment regarding the mt8192 support, but I'll write it on the v2 of this series. Thanks, Nícolas _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2023-04-28 20:01 UTC | newest] Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-07 16:34 [PATCH 0/4] Add LVTS support for mt8192 bchihi 2023-03-07 16:34 ` bchihi 2023-03-07 16:34 ` [PATCH 1/4] dt-bindings: thermal: mediatek: Add LVTS thermal controller definition " bchihi 2023-03-07 16:34 ` bchihi 2023-03-08 9:20 ` AngeloGioacchino Del Regno 2023-03-08 9:20 ` AngeloGioacchino Del Regno 2023-03-09 16:17 ` Krzysztof Kozlowski 2023-03-09 16:17 ` Krzysztof Kozlowski 2023-03-07 16:34 ` [PATCH 2/4] thermal/drivers/mediatek/lvts_thermal: Add mt8192 support bchihi 2023-03-07 16:34 ` bchihi 2023-03-08 9:23 ` AngeloGioacchino Del Regno 2023-03-08 9:23 ` AngeloGioacchino Del Regno 2023-03-08 15:59 ` Balsam CHIHI 2023-03-08 15:59 ` Balsam CHIHI 2023-03-07 16:34 ` [PATCH 3/4] arm64: dts: mediatek: mt8192: Add thermal zones and thermal nodes bchihi 2023-03-07 16:34 ` bchihi 2023-03-07 16:34 ` [PATCH 4/4] arm64: dts: mediatek: mt8192: Add temperature mitigation threshold bchihi 2023-03-07 16:34 ` bchihi 2023-03-09 5:04 ` [PATCH 0/4] Add LVTS support for mt8192 Chen-Yu Tsai 2023-03-09 5:04 ` Chen-Yu Tsai 2023-03-09 10:47 ` Balsam CHIHI 2023-03-09 10:47 ` Balsam CHIHI 2023-03-22 12:48 ` Balsam CHIHI 2023-03-22 12:48 ` Balsam CHIHI 2023-03-25 4:33 ` Chen-Yu Tsai 2023-03-25 4:33 ` Chen-Yu Tsai 2023-03-28 0:20 ` Balsam CHIHI 2023-03-28 0:20 ` Balsam CHIHI 2023-03-28 3:12 ` Chen-Yu Tsai 2023-03-28 3:12 ` Chen-Yu Tsai 2023-03-29 8:05 ` Balsam CHIHI 2023-03-29 8:05 ` Balsam CHIHI 2023-04-24 22:21 ` Nícolas F. R. A. Prado 2023-04-24 22:21 ` Nícolas F. R. A. Prado 2023-04-25 8:36 ` Balsam CHIHI 2023-04-25 8:36 ` Balsam CHIHI 2023-04-25 9:59 ` Chen-Yu Tsai 2023-04-25 9:59 ` Chen-Yu Tsai 2023-04-25 11:28 ` Balsam CHIHI 2023-04-25 11:28 ` Balsam CHIHI 2023-04-26 23:20 ` Nícolas F. R. A. Prado 2023-04-26 23:20 ` Nícolas F. R. A. Prado 2023-04-27 14:08 ` Balsam CHIHI 2023-04-27 14:08 ` Balsam CHIHI 2023-04-28 20:00 ` Nícolas F. R. A. Prado 2023-04-28 20:00 ` Nícolas F. R. A. Prado
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.